-
QUERVERWEIS AUF ZUGEHÖRIGE ANMELDUNGEN
-
Diese Anmeldung beansprucht das Prioritätsdatum der U.S. Provisional Patent Application Serial No. 61/552,931 mit dem Titel: ”Verfahren zum Bereitstellen einer digitaler Signatur zum Sichern einer Flash-Programmierfunktion”, angemeldet am 28. Oktober 2011.
-
HINTERGRUND DER ERFINDUNG
-
1. Gebiet der Erfindung
-
Diese Erfindung bezieht sich allgemein auf ein Verfahren zum Authentifizieren von Files, die in eingebettete Steuergeräte programmiert sind, und insbesondere auf ein Verfahren zum Verwenden von digitalen Signaturen, die asymmetrische Schlüssel verwenden, um die Herkunftsquelle und den Inhalt von binären Files, die in eingebettete Steuergeräte von Automobilen programmiert sind, zu authentifizieren, welches verschiedene alternative Ansätze zum Handhaben der Inhalt- und Signatur-Files von ihrer Entstehung bis zu ihrem Gebrauch beinhaltet.
-
2. Diskussion des Standes der Technik
-
Je mehr die digitale Technologie Einzug in Automobile findet, desto mehr steigt die Angst vor Schadsoftware und Hardwaremanipulation. Insbesondere kann die Software, die benötigt wird, um verschiedene Steuergeräte auf einem Fahrzeug zu betreiben, aus vielen Herkunftsquellen kommen. Wenn ein Stück von raubkopierter Software (nicht authentifiziert und demzufolge nicht ordungsgemäß validiert) verwendet wird oder ein Stück von einer Schadsoftware verwendet wird, kann die Leistungsfähigkeit und Zuverlässigkeit des Fahrzeugs beeinträchtigt werden und das Fahrzeug und seine Systeme können ein unerwartetes Verhalten aufweisen.
-
Digitale Signaturen sind eine bekannte Technik, die dazu verwendet werden kann, um die Authentizität einer elektronischen Botschaft zu verifizieren. Digitale Signaturen wurden jedoch nicht weit zur Authentifizierung von in Steuergeräten eingebetteter Software und von anderen Inhalten wegen der Komplexität des Managements des oder der digitalen Signatur-Files von der Inhaltsquelle bis zur Ausführung des Inhalts auf dem Steuergerät verwendet. Es besteht ein Bedarf für ein Verfahren, um diese Beschränkung zu überwinden, so dass diese digitalen Signaturen von einem Automobilhersteller effektiv gehandhabt werden können und die Herkunftsquelle und der Inhalt von solchen Files, die in ein eingebettetes Steuergerät von einem Automobil programmiert werden, ordungsgemäß verifiziert werden können.
-
ZUSAMMENFASSUNG DER ERFINDUNG
-
Im Einklang mit den Lehren der vorliegenden Erfindung wird ein Verfahren zum Bereitstellen digitaler Signaturen zum Authentifizieren der Quelle und des Inhalts von binären Files, die in eingebettete Steuergeräte von Automobilen flashprogrammiert sind, offenbart. Ein Teil eines elektronischen Inhalts wird auf einem Signier-Server durch Erzeugung eines Hash-Werts digital signiert und unter Verwendung des privaten Schlüssels des Signierers verschlüsselt. Die Inhalt-Files und digitalen Signatur-Files werden dann unter Verwendung eines oder mehrerer alternativer Ansätze an ein Programmierwerkzeug geliefert, welches wiederum die Inhalt-Files und Signatur-Files auf das Steuergerät, auf welchem der Inhalt ausgeführt werden wird, lädt. Das Steuergerät verifiziert den Inhalt durch das Entschlüsseln des Signatur-Files, um den Hash-Wert wiederherzustellen, und durch das Vergleichen des Hash-Werts mit einem Hash-Wert, der aus dem Inhalt selbst berechnet wird. Mehrere Signatur-Files für ein Stück von einem Inhalt können benötigt werden und werden mit den offenbarten Verfahren verwendet.
-
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 Blockdiagramm eines Standardverfahrens zum Signieren und Verifizieren eines elektronischen Inhalts unter Verwendung einer digitalen Signatur;
-
2 ist ein Blockdiagramm von einem Verfahren zum Signieren und Verifizieren eines elektronischen Inhalts unter Verwendung einer digitalen Signatur mit der Lieferung von Inhalt- und Signatur-Files von einer Programmierquelle an ein ausführendes Steuergerät;
-
3 ist ein schematisches Diagramm, das zeigt, wie elektronischer Inhalt und eine digitale Signatur zu einem Steuergerät eines Fahrzeugs physisch geliefert werden;
-
4 ist ein Blockdiagramm eines ersten alternativen Verfahrens zum Liefern von Inhalt- und Signatur-Files von einer Quelle an einen Bestimmungsort;
-
5 ist ein Blockdiagramm eines zweiten alternativen Verfahrens zum Liefern von Inhalt- und Signatur-Files von einer Quelle an einen Bestimmungsort;
-
6 ist ein Blockdiagramm eines dritten alternativen Verfahrens zum Liefern von Inhalt- und Signatur-Files von einer Quelle an einen Bestimmungsort;
-
7 ist ein Blockdiagramm eines vierten alternativen Verfahrens zum Liefern von Inhalt- und Signatur-Files von einer Quelle an einen Bestimmungsort;
-
8 ist eine kleine Abänderung des vierten alternativen Verfahrens zum Liefern von Inhalt- und Signatur-Files von einer Quelle an einen Bestimmungsort;
-
9 ist ein Blockdiagramm eines fünften alternativen Verfahrens zum Liefern von Inhalt- und Signatur-Files von einer Quelle an einen Bestimmungsort; und
-
10 ist ein Blockdiagramm eines sechsten alternativen Verfahrens zum Liefern von Inhalt- und Signatur-Files von einer Quelle an einen Bestimmungsort;
-
DETAILLIERTE BESCHREIBUNG DER AUSFÜHRUNGSBEISPIELE
-
Die folgende Diskussion der Ausführungsformen der Erfindung, die auf Verfahren zum Bereitstellen digitaler Signaturen für das Authentifizieren der Quelle und des Inhalts von binären Files, die in eingebettete Steuergeräte von Automobilen programmiert sind, ist rein beispielhafter Natur und in keiner Weise dazu gedacht, die Erfindung oder ihre Anwendungen oder Verwendungen zu begrenzen. Beispielsweise sind die hier offenbarten Verfahren zum Authentifizieren der Quelle und des Inhalts von binären Files für ein elektronisches Steuergerät (ECU) eines Fahrzeugs. Wie von Fachleuten allerdings leicht erkannt werden wird, wird das Verfahren eine Anwendung für das Authentifizieren der Quelle und des Inhalts von binären Files andere Steuergeräte finden.
-
Viele moderne Fahrzeuge beinhalten elektronische Steuergeräte (ECUS) oder Controller, die den Betrieb der Fahrzeugsysteme, wie beispielsweise den Antriebsstrang, das Klimasteuersystem, das Infotainmentsystem, Bodysysteme, Chassissysteme und anderes steuern. Solche Steuergeräte erfordern eine spezielle anwendungsbezogene Software, um diese Steuerfunktionen auszuführen. Mit steigender Zahl und Komplexität dieser Steuergerate wächst auch die Furcht, die von Entwicklern von Schadsoftware ausgeht, so dass es wichtiger denn je ist, die Quelle und den Inhalt von binären Files, die auf Automobilsteuergeräte geladen werden, zu authentifizieren. Die Konsequenzen von der Verwendung von raubkopierter Software, die nicht ordungsgemäß validiert ist, oder schlimmer noch, schadhaft designt ist, in einem Fahrzeug-Steuergerät beinhaltet unerwartetes Verhalten des Fahrzeugs oder seiner Systeme, ein zunehmendes Risiko für den Diebstahl des Fahrzeugs, potentielles Manipulieren an Komponenten wie beispielsweise dem Kilometerzähler und der Verlust von anderen Fahrzeugmerkmalen und Funktionen.
-
1 ist ein Blockdiagramm 10 eines bekannten Verfahrens zum Verwenden digitaler Signaturen mit asymmetrischen Schlüsseln zum Authentifizieren von Files, die in Steuergeräten programmiert sind. 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.
-
In einem Signierschritt 12 wird ein Inhalt-File 14 bereitgestellt, wobei das Inhalt-File 14 ein Teil einer Software, ein Kalibrier-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 zu generieren. Der Hash-Wert 16 wird dann mit dem privaten Schlüssel des Signierers verschlüsselt, um eine digitale Signatur 18 zu erstellen.
-
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.
-
Wie oben erwähnt, ist die in 1 gezeigte digitale Signaturtechnik bekannt, aber es gibt viele Probleme in der Praxis beim Handhaben des Inhalt-Files 14 und der digitalen Signatur 18 von dem Signierschritt 12 bis zum Verifizierschritt 20. Die hier offenbarten Verfahren beseitigen diese Probleme.
-
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 und/oder ein Kalibrier-File, was allgemein als ein Inhalt-File 44 bekannt ist. Das Inhalt-File 44 ist typischerweise ein binäres File. Es wird gewünscht, 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 mithilfe des auf dem Signier-Server 48 abgespeicherten privaten Schlüssels verschlüsselt, wobei die Verschlüsselung die digitale Signatur 46 generiert. Die digitale Signatur 46 wird dann zurück an die Ablage 42 übermittelt.
-
An diesem Punkt liegen das Inhalt-File 44 und die digitale Signatur 46 beide in der Ablage 42. Die Herausforderung ist dann, das Inhalt-File 44 und die digitale Signatur 46 durch die verschiedenen Geschäftssysteme, 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 Produktionsdatenbank 56, die von der Produktionsabteilung des Automobilherstellers zum Verwalten elektronischer Files, welche als ”Teile” in der Produktion von Fahrzeugen installiert werden, verwendet wird. 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 aus 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 in Stand zu setzenden Fahrzeug bereitstellen kann. Details, wie das Inhalt-File 44 und die digitale Signatur 46 von der Ablage 42, der Produktionsdatenbank 56, der Service-Datenbank 62 und dem Programmierwerkzeug 68 gehandhabt werden, werden in den unten diskutierten Verfahren näher beschrieben.
-
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 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 der 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 des öffentlichen Schlüssels der Ablage 42 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 Bestimmung auf Gültigkeit 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 als eine von einem oder mehreren Kalibrier-Files auf der 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 Produktions-Datenbank 56 gezeigt ist. Der Transfer des Inhalt-Files 44 und der digitalen Signatur 46 an die Produktions-Datenbank 56 kann über ein Firmennetzwerk stattfinden. Die Produktions-Datenbank 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.
-
Das in 2 gezeigte Verfahren ist ein generischer Ansatz, um Inhalt- und digitale Signatur-Files von der Ablage 42 an die ECU 74 zu liefern. Mehrere alternative Ausführungsformen für das Verfahren zum Handhaben und Liefern des Files werden in Betracht gezogen, wie unten diskutiert werden wird. Im Allgemeinen kann die digitale Signatur 46 in das Inhalt-File 44 eingebettet, an das Inhalt-File 44 angehängt oder von dem Inhalt-File 44 entfernt werden. Darüber hinaus sind Szenarios möglich, wo mehr als eine digitale Signatur 46 notwendig ist und die Methodik für das Handhaben und Liefern des Files sich dieser Situation dann anpassen muss. Beispielsweise können mehr als eine digitale Signatur 46 notwendig sein, wenn ein Land fordert, dass ein Automobilhersteller den privaten Schlüssel, der in der Software verwendet wird, die in diesem Land verkauft wird, offenbart, wobei in diesem Fall der Automobilhersteller einen eindeutigen privaten Schlüssel für dieses Land verwenden will, welcher von dem privaten Schlüssel verschieden ist, den er für die Software in Fahrzeugen verwendet, welche er im Rest der Welt verkauft. Jede der einzelnen Ausführungsformen, die unten erörtert werden, bringt gewisse Vorteile und Merkmale mit sich. Ein Automobilhersteller kann eine diese Alternativen oder eine Mischung oder Kombination der Alternativen wählen, wie sie am besten für die Organisationsstruktur des Automobilherstellers, die Geschäftsabläufe und die IT-Geschäftssysteme am besten ist. In den alternativen Verfahren, die unten erörtert werden, sind drei digitale Signaturen gezeigt, aber es verständlich, dass mehr als drei oder weniger als drei in der Praxis verwendet werden können.
-
4 ist ein Blockdiagramm 90 für ein erstes alternatives Verfahren zum Liefern elektronischer Inhalt- und Signatur-Files von einer Quelle an einen Bestimmungsort. Zusätzlich zu dem Inhalt-File 44 und der digitalen Signatur 46 sind eine zweite digitale Signatur 96 und eine dritte digitale Signatur 98 gezeigt. In dem Verfahren aus dem Blockdiagramm 90 sind das Inhalt-File 44 und die digitalen Signaturen 46, 96 und 98 alle separate Files, die voneinander losgelöst vorliegen und jedes ihre eigene Teilenummer aufweist. Das bedeutet, dass dieses Verfahren vier Daten-Files und vier Teilenummern verwendet, um das Inhalt-File 44 und die digitalen Signaturen 46, 96 und 98 darzustellen. Jedes dieser Files würde eine eindeutige Teilenummer in der Materialliste aufweisen, würde in einem separaten Platz in der Produktionsdatenbank 56 und in der Servicedatenbank 62 abgespeichert und würde für die Produktion auf dieselbe Art und Weise, wie das für andere Software Teile gegenwärtig die Praxis ist, freigegeben oder genehmigt werden. Dieses Verfahren stellt ein großes Maß an Flexibilität bereit, da die Anzahl von digitalen Signatur-Files mit einem bestimmten Teil von elektronischem Inhalt verwendet werden könnte. Dieses Verfahren erfordert darüber hinaus kein spezifisches Programmieren des Bootloaders wie dies einhergehen würde mit der Produktionsabteilung oder der Serviceabteilung, um die ordnungsgemäße digitale Signatur (46, 96 oder 98) mit dem Inhalt-File 44 an das Programmierwerkzeug 68 bereitzustellen. Das Programmierwerkzeug 68 würde dann das Inhalt-File 44 und die digitalen Signaturen (46, 96 oder 98, welche auch immer von der Produktionsdatenbank 56 oder der Service-Datenbank 62 erhalten würde) an die ECU 74 herunterladen, wobei der Bootloader wie eingangs beschrieben, verfahren würde.
-
5 ist ein Blockdiagramm 100 für ein zweites alternatives Verfahren zum Liefern elektronischer Inhalt- und Signatur-Files von einer Quelle an ein Bestimmungsort. Bei dem Verfahren aus dem Blockdiagramm 100 wird, was auf der linken Seite gezeigt ist, das Inhalt-File 44 mit der digitalen Signatur 46 kombiniert, um ein einzelnes binäres File zu produzieren, das eine Teilenummer in der Materialmenge und den Datenbanken 56 und 62 darstellen würde. Analog dazu könnte das Inhalt-File 44 mit der digitalen Signatur 96 kombiniert werden, um ein zweites binäres File und ein zweites eine zweigeteilte Nummer zu produzieren, und das Inhalt-File 44 könnte mit der digitalen Signatur 98 kombiniert werden, um ein drittes binäres File und eine dritte Teilenummer zu produzieren. Das bedeutet, dass dieses Verfahren drei Daten-Files und drei Teilenummern verwendet, um das Inhalt-File 44 und die digitalen Signaturen 46, 96 und 98 darzustellen. Ähnlich zu dem ersten alternativen Verfahren aus der 4 würde jedes der Files in diesem Verfahren eine eindeutige Teilenummer in der Materialliste aufweisen, würde als ein separater Gegenstand in der Produktionsdatenbank 56 und der Servicedatenbank 62 gespeichert werden und würde in derselben Art und Weise, wie es derzeit für andere Softwareteile die Praxis ist, freigegeben oder für die Produktion genehmigt werden. Dieses Verfahren gewährleistet ebenfalls ein großes Maß an Flexibilität, da jede Zahl von digitalen Signatur-Files mit einem bestimmten Stuck von elektronischem Inhalt verwendet werden könnte. Auch bei diesem Verfahren würde es der Produktionsabteilung oder Serviceabteilung obliegen, das ordnungsgemäße Teile-File (das Inhalt-File 44 kombiniert mit einer der digitalen Signaturen 46, 96 oder 98) an das Programmierwerkzeug 68 bereitzustellen. Das Programmierwerkzeug 68 würde dann das kombinierte File auf die ECU 74 herunterladen, wobei der Bootloader wie oben beschrieben verfahren würde. In diesem Fall würde der Bootloader dazu programmiert werden, zu erkennen, dass der erste Teil des kombinierten Files, welches durch einen bestimmten Adressbereich dargestellt wird, die digitalen Signaturdaten enthält.
-
6 ist ein Blockdiagramm 140 für ein drittes alternatives Verfahren zum Liefern elektronischer Inhalt- und Signatur-Files von einer Quelle an einen Bestimmungsort. Dieses Verfahren ist ähnlich zu dem Verfahren aus der 5, mit der Ausnahme, dass in diesem Verfahren, das digitale Signatur-File in dem Inhalt-File 44 eingebettet ist im Gegensatz zu den zwei Files, die einfach kombiniert werden, wie es in dem zweiten alternativen Verfahren aus 5 der Fall war. Das bedeutet, dass die digitale Signatur 46 innerhalb des Inhalt-Files 44 eingebettet ist, um ein einzelnes binäres File zu produzieren, welches eine Teilenummer in der Materialmenge und den Datenbanken 56 und 62 darstellen würde. Analog dazu wäre die digitale Signatur 96 in dem Inhalt-File 44 eingebettet, um ein zweites binäres File und eine zweite Teilenummer zu produzieren, und die digitale Signatur 98 wäre in das Inhalt-File 44 eingebettet, um ein drittes binäres File zu produzieren und eine dritte Teilenummer. Dieses Verfahren verwendet demzufolge drei Daten-Files und drei Teilenummern, um das Inhalt-File 44 und die digitalen Signaturen 46, 96 und 98 darzustellen. Das Einbetten der digitalen Signatur-Files in das Inhalt-File 44 würde in gleicher Art und Weise vorgenommen werden, wie andere Daten, beispielsweise Teilenummern und Prüfsummen, gegenwärtig in Software-Files eingebettet werden. Wie beim zweiten alternativen Verfahren von oben wären die Verfahren und Werkzeuge für die Teilfreigabe und für den Teilewechsel nicht beeinträchtigt. In diesem dritten alternativen Verfahren müsste der Bootloader wissen, wo die digitalen Signaturdaten in dem Inhalt-File 44 eingebettet sind, so dass der Bootloader die digitalen Signaturdaten verwenden kann, um den entschlüsselten Hash-Wert 78 zu generieren und darüber hinaus kann der Bootloader die digitalen Signaturdaten weglassen, wenn er den berechneten Hash-Wert 84 bestimmt.
-
7 ist ein Blockdiagramm 160 für ein viertes alternatives Verfahren zum Liefern elektronischer Inhalt- und Signatur-Files von einer Quelle an einen Bestimmungsort. Da andere Datenquellen einbezogen sind, beinhaltet die 7 mehr als nur das Inhalt-File 44 und die verschiedenen digitalen Signatur-Files. Die Ablage 42, die in der 2 eingeführt wurde und oben diskutiert wurde, produziert drei Files. Eines dieser Files ist das Inhalt-File 44. Ein zweites File ist ein Metadaten-File 166, das eine Information über die Teilenummer, die von dem Inhalt-File 44 dargestellt wird, beinhaltet. Ein drittes File ist ein Signatur-Ablagefile 168, welches die digitalen Signaturen 46, 96 und 98 in einem einzelnen Datenfile, beispielsweise im eXtensible Markup Language (XML)-Format enthält. In dieser Alternative wird nur eine Teilenummer verwendet und die drei Files 44,166 und 168 haben alle gleiche File-Namen basierend auf der Teilenummer, mit verschiedenen File-Typ-Extensions. Die Files 44, 166 und 168 werden an die Produktionsdatenbank 46 geliefert. Die Servicedatenbank 62 würde ebenfalls die Files 44, 166 und 168 erhalten, ist aber der Einfachheit halber in der 7 weggelassen. Die Produktionsdatenbank 56 liefert die Files 44, 166 und 168 an das Programmierwerkzeug 68, welches wiederum die ECU 74 programmiert.
-
In dem vierten alternativen Verfahren aus der 7 muss noch gezeigt werden, wie das Programmierwerkzeug 68 und die ECU 74 Kenntnis erlangen, welche der Signaturen in dem Signaturaufbewahrungsfile 168 verwendet werden müssen, und wie der öffentliche Schlüssel bestimmt werden muss, um die Signatur zu entschlüsseln. Jede der digitalen Signaturen 46, 96 und 98 ist mit einer ”Produktionsoption” assoziiert, welche Parameter über das Fahrzeug identifiziert. Die Identifizierer für den öffentlichen Schlüssel und die Werte für jede der digitalen Signaturen 46, 96 und 98 sind in einer Schlüsseldatenbank 178 enthalten. Produktionsoptionsdaten sind in einer Optionsdatenbank 180 enthalten. Jedes Fahrzeug, das produziert wird, hat einen bekannten Produktionsoptionscode, der an das Programmierwerkzeug 68 von der Optionsdatenbank 180 geliefert wird. Durch Kenntnis des Produktionsoptionscodes für das Fahrzeug kann das Programmierwerkzeug 68 die geeignete zugehörige digitale Signatur unter den Signaturen 46, 96 und 98 auswählen und kann somit den ordnungsgemäßen öffentlichen Schlüssel aus der Datenbank 178 holen. Das Programmierwerkzeug 68 würde dann das Inhalt-File 44 und die ordnungsgemäße digitale Signatur (46, 96 oder 98) zur Validierung und Installation auf die ECU 74 herunterladen.
-
Im vierten alternativen Verfahren aus der 7 ist es ebenso möglich, das Programmierwerkzeug 68 in einen Trial-and-Error-Modus zu betreiben, ohne dass ein Zugang zu der Schlüsseldatenbank 178 oder zur Optionsdatenbank 180 besteht. In diesem Trial-and-Error-Modus würde das Programmierwerkzeug 68 die digitalen Signaturen 46, 96 und 98 an die ECU 74 zur selben Zeit senden und der Bootloader würde bestimmen, welche Signatur verwendet werden soll basierend auf seinem eingebetteten öffentlichen Schlüssel. Dieser Trial-and-Error-Modus erfordert ein weniger ausgeklügeltes Programmierwerkzeug 68 aber er erfordert eine Anpassung des Bootloader-Programms an die individuellen Fahrzeugoptionen.
-
Die 8 ist ein Blockdiagramm 190 des vierten alternativen Verfahrens aus der 7 mit einer kleinen Abweichung. In dieser Abweichung der vierten Alternative ist jede der digitalen Signaturen in ihrer eigenen File untergebracht. Das bedeutet, dass die digitale Signatur 46 in einem ersten XML-File 194 untergebracht ist. Die digitale Signatur 96 ist in einem zweiten XML-File 196 untergebracht und die digitale Signatur 98 ist in einem dritten XML-File 198 untergebracht. Die XML-Files 194, 196 und 198 werden zusammen mit dem Inhalt-File 44 und dem Metadaten-File 166 alle von der Ablage 42 generiert und werden alle an die Produktionsdatenbank 96 geliefert und sind alle für das Programmierwerkzeug 68 verfügbar. Hier wiederum haben alle Files – 44, 166, 194, 196 und 198 – gleiche Filenamen basierend auf der einzelnen Teilenummer mit unterschiedlichen File-Extensions. Ein Vorteil dieser Variation der vierten Alternative ist, dass eine neue digitale Signatur mit einem neuen XML-File bereitgestellt werden kann, ohne dabei ein neues Signaturaufbewahrungsfile 168 zu erzeugen. Die Geschäftsprozesse müssen jedoch so ausgelegt sein, dass sichergestellt wird, dass das neue digitale Signatur-XML-File an die Produktionsdatenbank 56 und das Programmierwerkzeug 68 geliefert wird. Die tatsächliche Auswahl einer digitalen Signatur und das Flashprogrammieren der ECU 74 mit dem Programmierwerkzeug 68 ist in dieser Abänderung die gleiche wie die für das vierte alternative Verfahren aus der 7 beschriebene.
-
9 ist ein Blockdiagramm 230 eines fünften alternativen Verfahrens zum Liefern elektronischer Inhalt- und Signatur-Files von einer Quelle an einen Bestimmungsort. Dieses Verfahren ist eine Erweiterung des zweiten alternativen Verfahrens aus der 5. In diesem Verfahren werden jedoch das Inhalt-File 44 und mehrere digitale Signatur-Files kombiniert und als ein File und eine Teilenummer freigegeben. Wie auf der linken Seite der 9 gezeigt wird, werden das Inhalt-File 44 und die digitalen Signaturen 46 und 96 kombiniert. Dieser Kombination wird eine Teilenummer gegeben. Die Kombination wird für die Produktion freigegeben. Die Kombination wird an die Produktionsdatenbank 56 transferiert usw. Wenn eine neue digitale Signatur benötigt wird, beispielsweise die digitale Signatur 98, dann würde eine neue Teilenummer erzeugt und freigegeben werden, wobei das File eine Kombination des Inhalt-Files 44 und der drei digitalen Signaturen 46, 96 und 98 wäre. Dieses fünfte alternative Verfahren ist flexibel, in dem eine einzelne Teilenummer und ein einzelnes File mit mehreren Schlüsseln oder Signaturen verwendet werden kann. Das Verfahren ist darüber hinaus einfach, indem es mit existierenden Geschäftsprozessen und Datenbanken arbeiten kann.
-
In dem fünften alternativen Verfahren aus der 9 ist es für das Programmierwerkzeug 68 notwendig, die ordnungsgemäße Signatur an die ECU 74 zu liefern. Dies kann über das oben diskutierte Trial-and-Error-Verfahren getan werden, wobei das Programmierwerkzeug 68 die digitalen Signaturen nacheinander versendet und die ECU 74 die Signatur, die zu dem öffentlichen Schlüssel, der in dem Bootloader eingebettet ist, passt, verwendet. Das Programmierwerkzeug 68 könnte auch eine Datenanfrage an die ECUs 74 abgeben, um die Identität des im Bootloader eingebetteten öffentlichen Schlüssels zu bekommen. Das Programmierwerkzeug 68 würde dann nur die geeignete digitale Signatur an die ECU 74 senden.
-
10 ist ein Blockdiagramm 200 für ein sechstes alternatives Verfahren zum Liefern elektronischer Inhalt- und Signatur-Files von einer Quelle an einen Bestimmungsort. In dieser Ausführungsform werden ECU-Inhalt und Sicherheitsparameter kombiniert und als einzelnes File freigegeben, um die Validierung der Programmierinformation vor dem Programmieren zu gestatten. Ein Inhalt-File 202 ist mitsamt seinem File-Header 204 und dem tatsächlichen Inhalt 206 gezeigt, das in die ECU programmiert werden soll. Obwohl oben nicht spezifisch gezeigt, beinhaltet das Inhalt-File 44 einen File-Header. In den oben diskutierten Ausführungsformen wurde das Inhalt-File 44 gehasht und der Hash wurde signiert. In dieser Ausführungsform wird der Inhalt 206 gehasht und der Hash-Wert wird in den File-Header 204 gesetzt. Der File-Header 204 wird anstelle des tatsächlichen Inhalts 206 signiert. Eine detaillierte Abbildung des File-Header 204 ist auf der rechten Seite gezeigt und beinhaltet einen Speicherplatz 212 für die Teile-Information mit Teilenummern, Adressbereichen, Modul-ID etc., einen Speicherplatz 216 für die Signatur und einen Speicherplatz 218 für die Signaturschlüssel-ID. Der Hash-Wert des Inhalts 206 ist in dem Speicherplatz 220 des File-Headers 204 gezeigt. Die Inhalte der Speicherplätze 212, 216, 218 und 220 wird in den Speicherplatz 222 platziert. Der File-Header 204 beinhaltet die Instruktionen, um den Teil, der vor dem Löschen und Schreiben des Flash validiert werden kann, zu programmieren. Der Lieferant, der die ECU-Inhalt-Files bereitstellt, würde die Signaturen mit denselben Freigabewerkzeugen, die In-House-Files prozessieren, erzeugen.
-
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 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 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.
