-
HINTERGRUND DER ERFINDUNG
-
1. Gebiet der Erfindung
-
Die vorliegende Erfindung bezieht sich allgemein auf ein System und ein Verfahren zum Installieren von Software auf ein Steuergerät, welches nicht erfordert, dass die Software einen autorisierten Sicherheitscode umfasst, und insbesondere auf ein System und ein Verfahren zum Installieren von Entwicklungssoftware auf ein elektronisches Steuergerät (ECU) eines Fahrzeuges aus der Produktion, welches nicht erfordert, dass die Software signiert werden muss.
-
2. Diskussion des Standes der Technik
-
Die meisten modernen Fahrzeuge beinhalten elektronische Steuereinheiten (ECUS), oder Steuergeräte, die den Betrieb der Fahrzeugsysteme, beispielsweise des Antriebsstrangs, des Klimasteuersystems, des Infotainment-Systems, der Body-Systeme, der Chassis-Systeme und dergleichen steuern. Diese Steuergeräte benötigen eine besondere 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 binären Files, die in Automobilsteuergeräte geladen werden, zu authentifizieren. Die Konsequenzen von der Verwendung von Software, die nicht einwandfrei autorisiert 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 den Verlust von anderen Fahrzeugmerkmalen und Funktionen.
-
Eine bekannte digitale Codiertechnik wird als asymmetrische Schlüsselkryptographie bezeichnet, die digitale Signaturen zum Authentifizieren von Files, die in Steuergeräte programmiert sind, verwendet. Wie von Fachleuten gut verstanden ist, verwendet die asymmetrische Schlüsselkryptographie ein Paar von mathematisch miteinander in Beziehung stehenden Schlüsseln, die als öffentlicher Schlüssel und als privater Schlüssel bekannt sind, um eine Botschaft zu verschlüsseln und zu entschlüsseln. Um eine digitale Signatur zu generieren, verwendet ein Signierer seinen privaten Schlüssel, der nur ihm selbst bekannt ist, um eine Botschaft zu verschlüsseln. Die digitale Signatur kann dann von einer anderen Partei später unter Verwendung des öffentlichen Schlüssels, der mit dem privaten Schlüssel des Signierers gepaart ist, entschlüsselt werden.
-
Flashing ist ein gut bekanntes Verfahren zum Hochladen von Software, Kalibrier-Files und anderen Anwendungen in den Flash-Speicher einer ECU eines Fahrzeugs oder eines anderen programmierbaren Gerätes. Ein Bootloader ist ein embedded Softwareprogramm, das auf die ECU geladen ist, das ein Interface zwischen der ECU und einem Programmierwerkzeug oder Gerät bereitstellt, welches die Software flashprogrammiert. Der Bootloader verwendet typischerweise asymmetrische Schlüsselkryptographie und speichert einen öffentlichen Schlüssel, der verwendet werden muss, um die digitale Signatur zu dekodieren, die von dem Programmierwerkzeug übermittelt wird, bevor der ECU gestattet wird, die Software oder die Kalibrierung auszuführen.
-
Beim Entwickeln und Testen neuer Versionen von Software- und Kalibrier-Files ist es gewöhnlicherweise wünschenswert, ein Steuergerät aus der Produktion zu verwenden, das bereits mit existierenden Files flashprogrammiert wurde, da dies eine kostengünstigere Alternative dazu darstellt, ein spezielles Steuergerät für reine Entwicklungszwecke bereitzustellen. Beim Installieren von Entwicklungssoftwarefiles in einem Steuergerät aus der Produktion muss das File korrekt signiert oder auf andere Art und Weise authentifiziert worden sein, bevor die ECU es erlauben wird, dass das File installiert wird. Das Erfordernis, einen autorisierten Benutzer Entwicklungssoftware-Files und Kalibrier-Files zu signieren, erfordert einen signifikanten Aufwand, Zeit und Ressourcen. Wenn es jedoch relativ leicht ist, Entwicklungssoftwarefiles auf eine ECU zu installieren, was das Umgehen der Signaturforderung zum Authentifizieren eines Files für einen autorisierten Benutzer beinhaltet, wird es jedoch leichter für einen Hacker, die ECU in eine Konfiguration zu versetzen, die keine Signatur erfordert. Dies würde wünschenswert sein, um eine sichere Prozedur bereitzustellen, wobei ein Steuergerät aus der Produktion, das dazu verwendet worden ist, Entwicklungssoftware zu testen nicht dazu zu benötigen, um eine Signatur auf die Software flash zu programmieren. Es wäre jedoch immer noch sicher genug, um potentielle Hacker daran zu hindern, diese gleiche Operation auszuführen.
-
Wenn eine große Anzahl von Steuergeräten aus der Produktion für ein bestimmtes Modul auf einem Fahrzeug existiert und ein Verfahren entwickelt wäre, um die Entwicklungssoftware auf eines dieser Steuergeräte für Test- und Entwicklungszwecke flash zu programmieren, wenn genau diese Technik jemals außerhalb einer sicheren Entwicklungsumgebung zugelassen worden wäre, dann wären all die Steuergeräte aus der Produktion gegenüber diesem Risiko verwundbar. Demzufolge muss das Verfahren zum Installieren eines Steuergeräts, um eine Entwicklungssoftware zu akzeptieren, welche nicht für ein bestimmtes Steuergerät signiert wurde, sicher genug sein, um einen potentiellen Hacker daran zu hindern, Zugang zu diesem Steuergerät zu erlangen, und darüber hinaus auch noch sicher genug sein, wobei wenn der potentielle Hacker keinen Zugang zu dieser Technik für dieses Steuergerät erlangt hat, dass die Technik nicht für all die anderen Steuergeräte derselben Art verwendbar wäre.
-
ZUSAMMENFASSUNG DER ERFINDUNG
-
Im Einklang mit den Lehren der vorliegenden Erfindung werden ein System und ein Verfahren zum Installieren von Software auf ein sicheres Steuergerät offenbart, welches nicht erfordert, dass die Software korrekt signiert ist. Das Verfahren beinhaltet die Verwendung eines Umgehungsflags in dem Steuergerät, welches identifiziert, ob ein Filevalidierungsverfahren erforderlich ist, um das File zu installieren. Das Verfahren beinhaltet ferner das Ausführen einer Vorkontrolloperation, um zu bestimmen, ob vorbestimmte Parameter des Files eingehalten worden sind. Das Verfahren beinhaltet ferner das Installieren des Files in einen Speicher in das Steuergerät, wenn die Vorkontrolloperation befriedigend ausgeführt wurde. Das Verfahren beinhaltet ferner das Bestimmen, ob das File eine korrekte Signatur aufweist, und das Anzeigen, dass die Signatur korrekt ist, wenn das Umgehungsflag gesetzt ist. Das File wird für die Installation zugelassen, wenn die Signatur als korrekt angezeigt wird.
-
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 ein schematisches Blockdiagramm, das ein Verfahren zum Verifizieren einer digitalen Signatur zeigt;
-
2 ist ein Blockdiagramm für ein Verfahren zum Signieren und Verifizieren eines elektronischen Inhalts unter Verwendung einer digitalen Signatur, welches die Lieferung von Inhalt- und Signatur-Files von einer Programmierquelle zum Ausführen eines Steuergeräts beinhaltet;
-
3 ist ein schematisches Diagramm, das zeigt, wie ein elektronischer Inhalt und eine digitale Signatur physikalisch an ein Steuergerät in einem Fahrzeug geliefert werden;
-
4 ist ein Blockdiagramm, das ein Verfahren zum Umgehen eines Sicherheitscodes für ein Steuergerät aus der Produktion zeigt;
-
5 ist ein Blockdiagramm für ein Speichersegment eines Steuergeräts; und
-
6 ist ein Flussdiagramm, das ein Verfahren zum sicheren Flashprogrammieren signierter Softwareteile zeigt.
-
DETAILLIERTE BESCHREIBUNG DER AUSFÜHRUNGSBEISPIELE
-
Die folgende Diskussion der Ausführungsformen der Erfindung, die auf ein System und ein Verfahren zum Installieren einer Software auf ein Steuergerät gerichtet ist, ohne dass dabei die Software signiert werden muss, ist rein beispielhafter Natur und in keiner Weise dazu gedacht, die Erfindung oder ihre Anwendungen oder Verwendungen einzuschränken. Beispielsweise hat die hier diskutierte Technik eine besondere Anwendung bei einer ECU auf einem Fahrzeug. Fachleute können jedoch leicht erkennen, dass die Technik eine Anwendung bei anderen Steuergeräten haben kann.
-
1 ist ein Blockdiagramm 10 eines bekannten Verfahrens zum Verwenden asymmetrischer Schlüsselkryptographie zum Authentifizieren von Files, die in Steuergeräten programmiert werden. Wie Fachleuten gut bekannt ist, verwendet die asymmetrische Schlüsselkryptographie ein Paar von mathematisch miteinander in Beziehung stehenden Schlüsseln, die als privater Schlüssel und öffentlicher Schlüssel bekannt sind, um eine Botschaft zu verschlüsseln und zu entschlüsseln. Um eine digitale Signatur zu erstellen, verwendet ein Signierer seinen privaten Schlüssel, der nur ihm selbst bekannt ist, um eine digitale Botschaft zu verschlüsseln. Die digitale Signatur kann dann später von einer anderen Partei mithilfe des öffentlichen Schlüssels entschlüsselt werden, der mit dem privaten Schlüssel des Signierers gepaart ist, um ein File oder eine Botschaft zu authentifizieren.
-
In einem Signierschritt 12 wird ein Inhalt-File 14 bereitgestellt, wobei das Inhalt-File 14 ein Teil einer Software, ein kalibriertes File oder anderer ”soft-part”-Inhalt sein kann, um in einem Steuergerät verwendet zu werden. Eine Hash-Berechnung wird auf dem Inhalt-File 14 ausgeführt, um einen Hash-Wert 16 des Inhalt-Files 14 zu generieren. Der Hash-Wert 16 wird dann mit dem privaten Schlüssel des Signierers verschlüsselt, um eine digitale Signatur 18 zu erstellen, wobei die digitale Signatur 18 nur für dieses jeweilige Inhalt-File gut ist.
-
Die digitale Signatur 18 und das Inhalt-File 14 werden dann in einem Verifizier-Schritt 20 verwendet, der dann durch den Bootloader in der ECU in der Anwendung, die hierin diskutiert wird, ausgeführt werden würde. Die digitale Signatur 18 wird unter Verwendung des öffentlichen Schlüssels des Signierers entschlüsselt, um einen entschlüsselten Hash-Wert 22 zu generieren. In der Zwischenzeit wird eine Hash-Berechnung auf dem Inhalt-File 14 von dem Verifizierer ausgeführt, um einen berechneten Hash-Wert 24 zu generieren. Im Kasten 26 wird der entschlüsselte Hash-Wert 22 mit dem berechneten Hash-Wert 24 verglichen. Falls der entschlüsselte Hash-Wert 22 mit dem berechneten Hash-Wert 24 übereinstimmt, dann wird im Oval 28 eine Gültigkeitsbestimmung ausgegeben und das Inhalt-File 14 wird verwendet. Falls der entschlüsselte Hash-Wert 22 nicht mit dem berechneten Hash-Wert 24 übereinstimmt, dann wird eine Bestimmung der Ungültigkeit im Oval 30 ausgegeben und das Inhalt-File 14 wird nicht verwendet.
-
2 ist ein Blockdiagramm 40, das ein Verfahren zum Signieren und Verifizieren eines elektronischen Inhalts mithilfe einer digitalen Signatur, welches die Lieferung von Inhalt- und Signatur-Files von einer Programmierquelle an ein ausführendes Steuergerät beinhaltet. Eine Fileaufbewahrung 42 speichert eine ausführbare Software, ein kalibriertes File oder ein anderes ”soft-part” File, was zusammen als ein Inhalt-File 44 bekannt ist, wobei das Inhalt-File 44 typischerweise ein binäres File ist. Es ist wünschenswert, eine digitale Signatur 46 für das Inhalt-File 44 zu erhalten. Um für das Inhalt-File 44 eine digitale Signatur zu erhalten, wird das Inhalt-File 44 an einen Signier-Server 48 übermittelt. Auf dem Signier-Server 48 wird eine Hash-Berechnung auf dem Inhalt-File 44 ausgeführt, um einen Hash-Wert 52 zu generieren. Der Hash-Wert 52 wird unter Verwendung des privaten Schlüssels des Signier-Servers 48 verschlüsselt, wobei die Verschlüsselung die digitale Signatur 46 generiert. Die digitale Signatur 46 wird dann zurück an die Aufbewahrung 42 übermittelt.
-
An diesem Punkt liegen das Inhalt-File 44 und die digitale Signatur 46 beide in der Aufbewahrung 42. Die Herausforderung ist dann, das Inhalt-File 44 und die digitale Signatur 46 durch die verschiedenen Anwendungssysteme, die von dem Automobilhersteller verwendet werden, zu übermitteln, und das Inhalt-File 44 auf einem Steuergerät in einem Fahrzeug zu installieren und zu validieren. Im Allgemeinen wird ein Automobilhersteller zumindest zwei Organisationen oder Abteilungen haben, die für das Installieren von Software- und Kalibrier-Files auf Steuergeräten in Fahrzeugen verantwortlich sind, nämlich die Produktion und der Service. Die 2 zeigt eine Herstellungsdatenbank 56, die von der Produktionsabteilung des Automobilherstellers zum Verwalten elektronischer Files, welche als ”Teile” in der Produktion von Fahrzeugen installiert sind, verwendet werden. Die 2 zeigt analog dazu eine Service-Datenbank 62, die von der Serviceabteilung des Automobilherstellers zum Verwalten elektronischer Files, die als ”Service-Teile” in Fahrzeugen installiert sind, an welchen in einer Service-Werkstatt gearbeitet wird. Wie in der 2 ersichtlich ist, erhalten sowohl die Produktionsdatenbank 56 als auch die Service-Datenbank 62 Kopien des Inhalt-Files 44 und der digitalen Signatur 46, welche für die jeweiligen Funktionen der Produktionsabteilung und der Service-Abteilung verwendet werden.
-
Um das Inhalt-File 44 tatsächlich auf ein Steuergerät in einem Fahrzeug zu installieren, wird ein Programmierwerkzeug 68 verwendet. Wie gezeigt, erhält das Programmierwerkzeug 68 ebenfalls eine Kopie des Inhalt-Files 44 und die digitale Signatur 46. Das bedeutet, dass die Produktionsabteilung das Inhalt-File 44 und die digitale Signatur 46 von der Produktionsdatenbank 56 an das Programmierwerkzeug 68 für die Installation auf einem neu produzierten Fahrzeug bereitstellen kann, oder, dass die Service-Abteilung das Inhalt-File 44 und die digitale Signatur 46 von der Service-Datenbank 62 an das Programmierwerkzeug 68 für die Installation auf einem zu wartenden Fahrzeug bereitstellen kann.
-
Der nächste Schritt für das Programmierwerkzeug 68 ist es, das Inhalt-File 44 an ein Steuergerät in einem Fahrzeug zu installieren. Die ECU 74 ist in diesem Beispiel das Steuergerät, das das Inhalt-File 44 tatsächlich verwenden wird. Nachfolgend findet eine kurze Diskussion der Architektur der ECU 74 statt. Die Software auf der ECU 74 besteht aus einem Bootloader, einer ausführbaren Software und einem oder mehreren Kalibrier-Files. Zu Diskussionszwecken wird angenommen, dass die ECU 74 eine einzelne Central Processing Unit (CPU) aufweist. In tatsächlichen Fahrzeugen könnte die ECU 74 mehrere CPUs aufweisen und jede dieser CPUs würde einen Bootloader, eine ausführbare Software und eines oder mehrere Kalibrier-Files aufweisen.
-
Der Bootloader in der ECU 74 ist für das Validieren und Installieren neuer ausführbarer Software- und Kalibrier-Files verantwortlich. Die in diesem Absatz beschriebenen Funktionen werden demnach von dem Bootloader in der ECU 74 ausgeführt. Das Programmierwerkzeug 68 übermittelt das Inhalt-File 44 und die digitale Signatur 46 an die ECU 74. Die digitale Signatur 46 wird von dem Bootloader unter Verwendung eines in der Ablage 42 liegenden öffentlichen Schlüssels entschlüsselt, um einen entschlüsselten Hash-Wert 78 zu generieren. Der öffentliche Signierschlüssel kann in der ECU 74 vorhanden sein oder an die ECU 74 in Verbindung mit dem Inhalt-File 44 und der digitalen Signatur 46 geliefert werden. In der Zwischenzeit wird eine Hash-Berechnung auf dem Inhalt-File 44 von dem Bootloader ausgeführt, um einen berechneten Hash-Wert 84 zu generieren. Im Kasten 80 wird der entschlüsselte Hash-Wert 78 mit dem berechneten Hash-Wert 84 verglichen. Falls der entschlüsselte Hash-Wert 78 mit dem berechneten Hash-Wert 84 übereinstimmt, dann wird eine Gültigkeitsbestimmung 88 erlassen, und das Inhalt-File 44 wird verwendet. Falls das zu verwendende Inhalt-File 44 eine ausführbare Software ist, installiert der Bootloader diese als neue ausführbare Software auf der ECU 74. Falls das zu verwendende Inhalt-File 44 ein Kalibrier-File ist, installiert der Bootloader dieses von einem oder mehreren Kalibrierfiles in die ECU 74. Falls der entschlüsselte Hash-Wert 78 nicht mit dem berechneten Hash-Wert 84 übereinstimmt, dann wird eine Bestimmung 86 auf Ungültigkeit erlassen und das Inhalt-File 44 wird nicht auf der ECU 74 verwendet.
-
Die 3 ist ein schematisches Diagramm, das zeigt, wie elektronische Inhalt-Files und digitale Signatur-Files physikalisch an ein Steuergerät eines Fahrzeugs geliefert werden. Ein Fahrzeug 36 beinhaltet die in 2 gezeigte und oben diskutierte ECU 74. Die ECU 74 kann den Motor, das Getriebe, das Chassis, den Body, das Infotainment oder ein anderes System auf dem Fahrzeug 36 steuern. Das Inhalt-File 44 und die digitale Signatur 46 werden an eine zentrale Datenbank geliefert, die hier als die Produktionsdatenbank 56 gezeigt ist. Der Transfer des Inhalt-Files 44 und der digitalen Signatur 46 an die Produktionsdatenbank 56 kann über ein Firmennetzwerk stattfinden. Die Produktionsdatenbank 56 stellt das Inhalt-File 44 und die digitale Signatur 46 dem Programmierwerkzeug 68 zur Verfügung, wobei dieser Transfer durch Anfügen des Programmierwerkzeugs 68 an einen Computer, der Zugang zu der Datenbank 56 hat, erreicht werden kann. Das Programmierwerkzeug 68 kommuniziert mit der ECU 74 über eine Verbindung 38, die drahtgebunden oder drahtlos sein kann. Mit der hergestellten Verbindung 38 können das Inhalt-File 44 und die digitale Signatur 46 von dem Programmierwerkzeug 68 auf die ECU 74 runtergeladen werden, wobei der Bootloader die oben diskutierten Sicherheitsverifikationsfunktionen ausführen kann.
-
Die vorliegende Erfindung schlägt eine Technik zum Gestatten an eines Steuergeräts aus der Produktion vor, das bereits mit existierenden Files flashprogrammiert wurde, mit Entwicklungssoftware und Kalibierfiles zum Testen, Verifizieren, Analysieren etc., zu flashprogrammieren, ohne, dass dabei die Entwicklungssoftwarefiles und/Kalibrierfiles mit einer Signatur oder einem anderen Validiercode signiert oder anderweitig authentifiziert werden müssen, um das Steuergerät aus der Produktion für die Produktentwicklung leichter und billiger und besser zu verwenden. Wie unten diskutiert werden wird, wird das Verfahren so durchgeführt, dass nur ein einzelner bestimmter Steuergerätschritt eingerichtet werden wird, um mit der Entwicklungssoftware ohne Signatur flashprogrammiert zu werden, und nicht alle Steuergeräte von diesem bestimmten Steuergerätetyp.
-
4 ist ein Flussdiagramm 90, wobei der zeitliche Fortschritt von oben nach unten ein Verfahren für die oben allgemein vorgestellte Technik veranschaulicht und einen Kasten 92 beinhaltet, der ein sicheres Steuergerät aus der Fahrzeugproduktion, d. h. ein Steuergerät, das nur designierte Software akzeptiert, oder ein Steuergerät allgemein veranschaulicht, wobei der Kasten 94 einen Ingenieur oder Techniker darstellt, der die Verwendung des Steuergeräts 92 aus der Produktion wünscht, um für Entwicklungszwecke eine Produktentwicklung durchzuführen, wobei der Ingenieur 94 ein Programmierwerkzeug der oben bezeichneten Art verwenden würde, um Zugang zu dem Steuergerät 92 zu erlangen und einen Server 96, der eine bekannte, vertrauenswürdige und abgekoppelte Datenbank oder ein ”Backend” für die jeweilige Organisation darstellt, die dazu in der Lage ist, Authentifizierung, Autorisierung und Zugang für Dienstleistungen (AAA) für die jeweilige Anwendung zu gewähren.
-
Sobald der Ingenieur 94 es wünscht, das Steuergerät 92 zu verwenden, d. h. in das Steuergerät nicht signierte Software und/oder Kalibrier-Files hinein zu programmieren, wird der Ingenieur 94 über das Programmierwerkzeug eine Anfrage für eine Steuergeräteinformation auf der Leitung 98 senden, um das Signatur-Validierungserfordernis auszusetzen oder zu umgehen oder den Signaturschlüssel, der dazu verwendet wird, die digitalen Signaturen zu verifizieren, zu ersetzen. Sobald das Steuergerät 92 die Anfrage auf der Leitung 98 erhält, wird es dazu übergehen, ein Steuergeräteinformationsticket, welches auf der Leitung 100 bereitgestellt wird, zu erzeugen. Dieses Ticket wird an den Ingenieur 94 über das Programmierwerkzeug auf der Leitung 102 übergeführt. Das Informationsticket ist eine Nachricht, welche jede eindeutige Information beinhalten kann, die dieses spezielle Steuergerät identifizieren kann, beispielsweise eine Modul ID-Nummer, eine Komponentenseriennummer oder eine Rückverfolgungsnummer aus der Produktion und wie unten im Detail diskutiert werden wird, möglicherweise eine Anfrage oder ein anderes Erfordernis, das anerkannt oder beantwortet werden muss, um das Steuergerät 92 zu befriedigen, um das Signier-Erfordernis zu überschreiben oder zu umgehen.
-
Der Ingenieur 94 loggt sich dann auf dem Server 96, der von der Linie 104 dargestellt wird, ein, um von dem Server 96 das Steuergeräteinformationsticket validiert und genehmigt zu bekommen, wobei der Ingenieur 94 und der Server 96 die notwendige Information austauschen, so dass der Server 96 weiß, dass der Ingenieur 94 ein autorisierter Benutzer auf dem Server 96 ist. Der Server 96 wird an einen sicheren entfernten Ort abgelegen zu dem Ort des Ingenieurs 94 und zu dem Steuergerät 92 angeordnet sein, wobei der Ingenieur 94 zu dem Server 96 auf jede geeignete Art und Weise, beispielsweise durch ein Keyboard auf einem PC, einem Touch-Screen etc. Zugang erlangt, und wobei die Verbindung zu dem Server 96 durch jede geeignete sichere Verbindung, beispielsweise eine drahtlose, sichere Telefonleitung etc., erfolgen kann. Sobald der Ingenieur 94 sich auf dem Server 96 eingeloggt hat, übermittelt der Ingenieur 94 dann über den gleichen Prozess, den er beim Einloggen gemacht hat, das Steuergerätinformationsticket an den Server 96 auf der Leitung 106. Basierend auf der von dem Steuergeräteinformationsticket bereitgestellten Informationen erzeugt der Server 96 ein Authentifizierungsticket, dargestellt mit der Linie 108, wobei das Authentifizierungsticket von dem Server 96 signiert wird und als ein File-Header mit einer spezifischen Modul-ID sein kann. Es wird angemerkt, dass der Server 96 das Format des File-Headers kennen muss.
-
5 ist eine Darstellung eines Authentifizierungstickets 120 der oben erwähnten Art, die es dem Steuergerät 92 gestattet, zu validieren, dass der Ingenieur 94 ein autorisierter Benutzer ist. Der Server 96 erzeugt das Ticket 120, das die Steuergeräteinformation im der Sektion 122 beinhaltet, die das Steuergerät 92 identifiziert und die Antwort auf die Anfrage beinhaltet, so dass das Authentifizierungsticket 120 nur für ein einzelnes spezifisches Steuergerät 92 gültig ist. In der Sektion 124 kann das Authentifizierungsticket 120 einen Parameter beinhalten, der den Zweck beschreibt, warum der Ingenieur 94, das Steuergerät 92 aktualisieren möchte, beispielsweise das Umgehen der Signaturvalidierung für die Softwarefiles und/oder den Kalibrierfile, das Entsperren des Steuergeräts 92, das Ersetzen eines Signaturvalidierungsschlüssels, das Aktualisieren spezieller Parameter etc. In der Sektion 126 kann das Authentifizierungsticket 120 einen Validierungscode beinhalten, der die Lebensdauer des Tickets 120 definiert, beispielsweise den Einmalgebrauch, einen Fahrzyklus etc. In der Sektion 128 kann das Ticket 120 eine signierte Information, beispielsweise einen Signaturwert, eine Signierer ID etc. beinhalten.
-
Der Server 96 sendet dann das Authentifizierungsticket 120 an den Ingenieur 94 auf der Leitung 110 durch eine Verbindung, die bereits bestanden hat, und der Ingenieur 94 sendet dann das Authentifizierungsticket 120 an das Steuergerät 92 durch das Programmierwerkzeug auf der Leitung 112, wo es von dem Steuergerät 92 dargestellt mit der Linie 114 verarbeitet wird. Die Information in dem Authentifizierungsticket 120 wird von dem Steuergerät 92 verarbeitet, um einzurichten, dass das Authentifizierungsticket gültig ist und es setzt die geeigneten Flags oder liefert das geeignete Befähigungsschema, d. h. es wird dem Ingenieur 94 gestattet, nun die unsignierten Entwicklung-Software-Files und/oder Kalibrier-Files auf dem Steuergerät 92 zu installieren. Das Authentifizierungsticket 120, das von dem Server 96 erzeugt wurde, benachrichtigt das Steuergerät 92, welche Art von Information es benötigt, um zu wissen, um das Ticket zu verifizieren, und um das Steuergerät 92 zu aktualisieren. Das Steuergerät 92 schaut auf das Authentifizierungsticket 120 und bestimmt, ob es die geeignete Signatur oder den geeigneten Code und die ID-Information besitzt, die speziell für dieses Steuergerät 92 benötigt wird.
-
Wie oben erwähnt, kann das Steuergeräteinformationsticket, dass von dem Steuergerät 92 erzeugt wurde, eine Art von Abfrage oder anderen Code, welcher in dem Authentifizierungsticket 120 beinhaltet wird, beinhalten, welches von dem Server 96 erzeugt wurde, so dass, wenn der Ingenieur 94 das Authentifizierungsticket 120 zurück an das Steuergerät 92 sendet, eine bestimmter Abfrage oder Code beinhaltet werden muss, so dass das Steuergerät 92 weiß, dass dies nicht ein vorhergehendes Authentifizierungsticket für eine andersartige Programmieroperation ist. Demzufolge muss der Ingenieur 94 jedes Mal, wenn er das Steuergerät 92 aus einem Produktionsbetrieb in einen Entwicklungsbetrieb umschalten möchte, ein neues Authentifizierungsticket bekommen, indem er zuerst das Steuergeräteinformationsticket von dem Steuergerät 92 erhält. Der Server 92 verwendet die Information in dem Steuergeräteinformationsticket, um das Authentifizierungsticket 120 mit einem korrekten Code zu erzeugen, der es gestattet, dass das Steuergerät 92 weiß, dass es korrekt validiert wurde und dass der Ingenieur 94 ein autorisierter Benutzer ist. Demzufolge muss die Information, die identifiziert, dass das Steuergerät, eine Zufallszahl oder eine andere Abfrageidentifikation und/oder beide, nämlich die Steuergeräteidentifizierungsnummer und eine Zufallszahl, benötigt werden. Der Vorteil, die Steuergeräte-ID für das Authentifizierungsticket 120 zu erhalten, liegt darin, dass der Ingenieur 94 nur einmal zu dem Server 96 gehen muss, um das Authentifizierungsticket für dieses spezielle Steuergerät zu erhalten. Wenn das Steuergerät 92 jedoch in den Produktionsbetrieb zurück geschaltet wird, würde das Authentifizierungsticket ohne die Abfrage dazu missbraucht werden können, das Steuergerät 92 zurück in den Produktionsbetrieb zu schalten.
-
Das oben erwähnte Verfahren zum Überschreiben des Signier-Erfordernisses für Flash-Entwicklung-Software-Files und/oder Kalibrier-Teile kann eine Signatur oder ein Authentifizierungsumgehungsflag in dem Steuergerät 92 setzen, um es zu gestatten, dass das Entwicklungsoftware-File in dem Steuergerät 92 flashprogrammiert werden kann. Alternativ dazu kann das oben erwähnte Verfahren zum Überschreiben der Signier-Erfordernisse dazu verwendet werden, um andere Zwecke als die Flash-Programmierung von Entwicklungssoftware-Files und/oder Kalibrier-Teilen auf einem Steuergerät aus der Produktion verwendet zu werden. Unter der Annahme, dass das Signaturumgehungsflag gesetzt worden ist, schlägt die vorliegende Erfindung ebenfalls ein Verfahren für einen Prozess vor, wie das Entwicklungssoftware-File und/oder ein Kalibrier-Teil in dem Steuergerät 92 dann flashprogrammiert werden wird. Es wird angemerkt, dass das Signaturumgehungsflag, wie oben erwähnt, nicht notwendigerweise ein Flag zum Umgehen eines Signaturerfordernisses sein muss, sondern es kann auch ein Flag sein, dass gesetzt wird, um andere Authentifizierungserfordernisse zu umgehen.
-
6 ist ein Flussdiagramm 130, das ein Verfahren zum Gestatten zeigt, wie Softwarefiles und/oder Kalibrierfiles, die in das Steuergerät 92 flashprogrammiert werden sollen, sowohl für die Situation, bei der ein Umgehungsflag gesetzt wurde oder eben nicht. Der in dem Flussdiagramm 130 gezeigte Algorithmus kann dazu verwendet werden, sowohl ein Softwarefile oder ein Kalibrierfile flash zu programmieren, wobei das Flashprogrammieren eines Softwarefiles oder eines Kalibrier-Files voneinander unabhängig wäre. In diesem Kontext bestimmt der Algorithmus zuerst, ob das File, das flashprogrammiert werden soll, ein Softwarefile oder ein Kalibrier-File ist im Kasten 132 und geht dann basierend auf dieser Bestimmung zu der Entscheidungsraute 134 über, um zu bestimmen, ob das Softwarefileumgehungsflag oder das Kalibrier File-Umgehungsflag gesetzt wurde oder nicht. Wenn das Umgehungsflag für das Softwarefile oder das Kalibrier-File nicht gesetzt wurde, muss das Flash-Programmieren des Softwarefiles oder des Kalibrier-Files unter Verwendung einer Signaturverifikation, wie oben erwähnt, validiert werden. Analog dazu muss dann das Software-File oder das Kalibrier-File, nicht wie oben erwähnt, validiert werden, wenn das Umgehungsflag gesetzt wurde.
-
Wenn das Umgehungsflag nicht gesetzt wurde, geht der Algorithmus zu der Entscheidungsraute 136 über, um eine Reihe von Vorkontrollen auszuführen, um zu bestimmen, ob das Software-File oder das Kalibrier-File das geeignete Format, beispielsweise eine bestimmte Header-Format-Identifikation, eine Signaturversion, eine Schlüsselidentifikation, einen Speicheradressbereich etc. aufweist, auszuführen, wobei jede geeignete Vorkontrolle für ein bestimmtes Softwarefile, Kalibrier-File, ein Steuergerät etc. in dem Vorkontrollverfahren verwendet werden kann. Geeignete aber nicht beschränkende Ausführungsbeispiele beinhalten einen Modul-ID-Check, der identifiziert, welche Art von File an das Steuergerät übergeben werden soll, d. h., ob es sich um ein Kalibrierfile oder eine Software handelt, einen Steuergerätecheck, um zu bestimmen, ob die Kompatibilitätsadressbereiche, die innerhalb der zugehörigen Bereiche programmiert werden, mit bekannten Bereichen für das Kalibrier-File oder das Softwarefile zusammengehören, ob ein Schlüssel, der verwendet werden soll, um die Signatur des Softwarefiles oder Kalibrier-Files, welches installiert werden soll, mit dem Schlüssel in dem Steuergerät kompatibel ist, zu berechnen, einen Sicherheitsgrad des Schlüssels, der verwendet wird, um die Signatur des Softwarefiles oder Kalibrier-Files, welches programmiert werden soll, kompatibel ist, mit dem Schlüsselsicherheitsgrad, der in dem Steuergerät abgelegt ist, zu berechnen, den Sicherheitsgrad des Softwarefiles oder Kalibrierfiles, welches programmiert werden soll, welches kompatibel mit dem Sicherheitsgrad im Steuergerät ist, die Kompatibilitäts-ID korrekt ist, die bestimmt, ob das Softwarefile oder das Kalibrierfile, das flashprogrammiert werden soll, kompatibel mit der Boot-Software in dem Steuergerät ist, ob der Zielname innerhalb des Files, das an das Steuergerät bereitgestellt wird, mit dem Steuergerät übereinstimmt, wobei beispielsweise falsche Files an das falsche Steuergerät gesendet werden können, das Ablaufdatum des Files, das flashprogrammiert werden soll, etc.
-
Wenn das Softwarefile oder das Kalibrierfile usw. in dem Vorkontrollschritt in der Entscheidungsraute 136 nicht die zugehörigen Vorkontrollidentifikationen enthalten, dann geht der Algorithmus zum Kasten 138 fort und berichtet einen Fehler und verbleibt im Boot-Modus und das File wird nicht flashprogrammiert. Wenn das Softwarefile oder das Kalibrier File den Vorkontrollschritt in der Entscheidungsraute 136 besteht, geht der Algorithmus zum Kasten 140 fort, wo das Software-File oder Kalibrier-File in dem Speicher abgelegt wird, wobei es authentifiziert und validiert wird. Der Flash-Programmierprozess wird für jedes einzelne File ausgeführt und beinhaltet das Löschen von Software- oder Kalibrier-File Anwesenheitsmustern, das Löschen von Flash-Speichersegmenten, dass Schreiben des Files auf den Flash-Speicher etc., was von Fachleuten gut verstanden ist. Die Files, die installiert werden sollen, können in den Speicher flashprogrammiert werden, bevor sie validiert werden, aufgrund von RAM-Speicher-Begrenzungen in dem Steuergerät für das Abarbeiten von Signaturen, Prüfsummen etc., wie oben erwähnt. Demzufolge flashprogrammiert der Bootloader die Software- oder Kalibrier-Files auf den nichtflüchtigen Speicher und verwendet die flashprogrammierten Software- oder Kalibrier-Files nur dann, wenn bestimmt wird, dass sie autorisiert sind, wobei im anderen Fall diese Software- oder Kalibrier-Files gelöscht werden. Die Vorhandenseinsmuster sind gut bekannte digitale Nachrichten, die ein Softwarefile oder ein Kalibrier-File verifizieren. Insbesondere kann der Bootloader bestimmen, dass die Software und/oder Kalibrier-Files vorhanden sind und gültig sind, indem das Vorhandensein von spezifischen digitalen Mustern überprüft wird, welche als Vorhandenseinsmuster innerhalb der Software- und/oder Kalibrier-File-Speicherblöcke bekannt sind. Die Vorhandenseinsmuster können an jeden geeigneten Platz in der Speichersektion bereitgestellt werden, mit der das Software- oder Kalibrier-File assoziiert sind, und diese befinden sich typischerweise an dem Ende der Speichersektion.
-
Sobald das Flash-Programmierverfahren ausgeführt wird bestimmt der Algorithmus, ob ein Prüfsummenverfahren ausgeführt werden sollte oder umgangen werden sollte in der Entscheidungsraute 142. Wie von Fachleuten gut verstanden wird, ist ein Prüfsummenverfahren ein Verfahren auf einem sehr hohen Validierungsgrad, um zu versichern, dass das Flash-Programmieren nicht korrumpiert war und alles, was flashprogrammiert werden sollte, wirklich flashprogrammiert wurde. Wie aus dem Stand der Technik gut bekannt ist, verwenden einige Flashprogrammier-Verfahren ein Prüfsummenverfahren zum Validieren, wohingegen andere Flashprogrammierverfahren dies nicht verwenden. Wenn der Prüfsummenvalidierprozess nicht umgangen worden ist, bestimmt der Algorithmus, ob der Prüfsummenvalidierprozess anzeigt, dass das Flashprogrammieren authentifiziert war und wenn nicht, geht er zu dem Kasten 138 fort, um einen Fehler zu melden und im Boot-Modus zu verbleiben. Wenn der Prüfsummenprozess umgangen wurde in der Entscheidungsraute 142, oder in der Entscheidungsraute 146 gültig war, dann validiert der Algorithmus die Signatur über den flashprogrammierten Speicher, wie oben erwähnt, im Kasten 144, um zu bestimmen, ob die installierte Softwarefiles oder Kalibrier-Files authentifiziert und gültig sind. Der Algorithmus bestimmt, ob die Signatur gültig ist in der Entscheidungsraute 148 und wenn dies nicht der Fall ist, geht er zu dem Kasten 138 über, um den Fehler zu berichten und im Boot-Modus zu verbleiben. Im anderen Fall schreibt der Algorithmus das Software-File oder das Kalibrier-File-Vorhandenseinsmuster, berichtet, dass die Flash-Programmierung erfolgreich war und verlässt den Boot-Modus, wenn all die Vorhandenseinsmuster im Kasten 150 gültig sind.
-
Wenn das Umgehungsflag in der Entscheidungsraute 134 gesetzt wird, was bedeutet, dass das Softwarefile oder das Kalibrier-File, welches flashprogrammiert werden soll, nicht durch ihre Signatur oder an einen anderen Sicherheitscode validiert werden muss, vollführt der Algorithmus immer noch das Vorkontrollverfahren in der Entscheidungsraute 152, wie oben erwähnt und wenn das Vorkontrollverfahren nicht funktioniert geht der Algorithmus zu dem Kasten 138 über, um den Fehler zu berichten und in dem Boot-Modus zu verbleiben. Es wird angemerkt, dass das Vorkontrollverfahren verschiedenartig sein kann, basierend darauf, ob das Umgehungsflag gesetzt oder nicht gesetzt wird, wobei das Vorkontrollverfahren wahrscheinlich weniger robust wäre, wenn das Umgehungsflag gesetzt wird. Demzufolge, wenn einige Vorkontrolloperationen ausgeführt werden, die nicht Teil des Vorkontrolltests sind, wenn das Umgehungsflag gesetzt wird nicht befriedigt werden, wird der Algorithmus immer noch zu dem Kasten 154 übergehen, um die Software flash zu programmieren.
-
Wenn das Vorkontrollverfahren in der Entscheidungsraute 152 durchgelaufen ist, löscht der Algorithmus die Vorhandenseinsmuster und Speichersegmente in dem Kasten 154 in der gleichen Art und Weise, wie es im Kasten 140 erfolgte, bestimmt, ob in der Entscheidungsraute 156 in der gleichen Art und Weise wie in der Entscheidungsraute 142 umgangen werden sollte, und bestimmt, ob die Prüfsumme in der Entscheidungsraute 160 gültig ist, in der gleichen Art und Weise, wie es in der Entscheidungsraute 156 vollzogen wurde. Im vorliegenden Fall, wo das Umgehungsflag gesetzt wurde, geht der Algorithmus immer noch dazu über, ein Verfahren auszuführen, um zu bestimmen, ob die Signatur im Kasten 158 gültig ist und berichtet, ob die Signatur gültig ist an die Signaturgültigkeitsentscheidungsraute 148. Mit anderen Worten auch wenn das Umgehungsflag gesetzt ist, versucht der Algorithmus immer noch, die Signatur zu authentifizieren und berichtet, dass diese gültig ist, obgleich er nicht weiß ob dies wirklich der Fall ist. Der Algorithmus berechnet, ob die Signatur gültig ist, wobei hauptsächlich aus Zeitgründen in dem Entwicklungsumgehungsbetrieb es einen gewissen Zeitaufwand für den Signaturvalidierungsprozess erforderlich ist, um in dem Entwicklungsprozess repliziert zu werden.
-
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 mithilfe elektrischer Phänomene Daten manipuliert und/oder transformiert. Diese Computer und elektrischen Geräte können verschiedene flüchtige und/oder nichtflü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 und 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.
