-
Die vorliegende Erfindung betrifft ein Steuergerät, insbesondere ein Motorsteuergerät und ein Verfahren zu dessen Betrieb.
-
Stand der Technik
-
In der Steuerungs- und Regelungstechnik wird als eingebettetes System (embedded system) jedweder elektronische Rechner oder Computer bezeichnet, der in einen technischen Kontext eingebunden und in diesem Sinne „eingebettet“ ist. Dabei übernimmt der Rechner Überwachungs-, Steuer- oder Regelfunktionen oder ist für eine Form der Daten- bzw. Signalverarbeitung zuständig, beispielsweise das Ver- bzw. Entschlüsseln, Codieren bzw. Decodieren oder Filtern.
-
Eingebettete Systeme nach dem Stand der Technik finden Anwendung in einer Vielzahl von Anwendungsbereichen und Geräten, beispielsweise in kraftfahrzeugtechnischen Steuergeräten (electronic control units, ECUs), Medizintechnik, Luft- und Raumfahrt, Haushaltsgeräten, Unterhaltungselektronik, Netzwerkgeräten oder Mobiltelefonen.
-
Zum Schutz vor Softwaremanipulationen ist in verschiedenen Produktplattformen die Applikation an das Gerät angepasst und irreversibel geschützt. Im Falle eines Motorsteuergerätes beispielsweise wird mitunter ein abgegrenzter Speicherblock und der darin enthaltene öffentliche Schlüssel mit Metadaten wie einer eindeutigen Kennung des Hauptprozessors (central processing unit, CPU) oder einer Seriennummer des Gerätes gesichert. Hierzu dienen etwa sogenannte Fuse-Bits des verwendeten Mikrocontrollers, die - einmal ähnlich einer „Schmelzsicherung“ (fuse) werksseitig konfiguriert - softwaremäßig nicht verändert werden können. Im Rahmen der Serienfertigung dient dieser fachsprachlich als „Fusen“ bezeichnete Verfahrensschritt zur Finalisierung des Steuergerätes, nachdem letzteres mit einer vorgesehenen Basissoftware (firmware) und Anwendungssoftware programmiert wurde. Auf diese Weise kann insbesondere eine unerlaubte Leistungssteigerung von Kfz-Motoren (chip tuning) durch nachträgliche Änderung der werksseitig festgelegten Steuerparameter unterbunden werden.
-
DE 10 2012 110 559 A1 offenbart ein Verfahren zum Authentifizieren eines Stücks von Firmware, welche auf einen Controller heruntergeladen werden soll. Das Verfahren beinhaltet das Signieren der Firmware oder eines ersten Teils der Firmware mit einem ersten privaten Schlüssel in einer ersten vertrauenswürdigen Quelle und das Signieren der Firmware oder eines zweiten Teils der Firmware mit einem zweiten privaten Schlüssel in einer zweiten vertrauenswürdigen Quelle. Das Verfahren beinhaltet ferner das Validieren der signierten Firmware oder des ersten Teils der Firmware unter Verwendung eines ersten öffentlichen Schlüssels in dem Controller und das Validieren der Firmware oder des zweiten Teils der Firmware unter Verwendung eines zweiten öffentlichen Schlüssels in dem Controller. Das Verfahren beinhaltet ferner das Authentifizieren der Firmware, falls die Firmware oder der erste Teil der Firmware von dem ersten öffentlichen Schlüssel in dem Controller validiert wird und die Firmware oder der zweite Teil der Firmware von dem zweiten öffentlichen Schlüssel in dem Controller validiert wird.
-
DE 10 2012 109 619 A1 offenbart ein Verfahren zum Bereitstellen digitaler Signaturen zum Authentifizieren der Quelle und des Inhalts von binären Files, welche in eingebettete Steuergeräte von Automobilen flashprogrammiert werden. Ein Teil eines elektronischen Inhalts wird auf einem Signier-Server durch das Erzeugen eines Hash-Werts und dem Verschlüsseln mit dem privaten Schlüssel des Signierers digital signiert. Das Inhalt-File und die digitalen Signatur-Files werden dann unter Verwendung eines von mehreren alternativen Ansätzen an ein Programmierwerkzeug geliefert, welches wiederum die Inhalt- und Signatur-Files auf das Steuergerat, auf dem der Inhalt ausgeführt werden wird, lädt. Das Steuergerät verifiziert den Inhalt durch Entschlüsseln des Signatur-Files, um den Hash-Wert wiederherzustellen und den entschlüsselten Hash-Wert mit einem Hash-Wert, der aus dem Inhalt selbst berechnet wurde, zu vergleichen.
-
DE 10 2014 208 385 A1 offenbart Verfahren zum sicheren Laden von Softwareobjekten in eine elektronische Steuereinheit. Die Verfahren enthalten das Empfangen eines ersten Softwareobjektes mit einem Zertifikat des öffentlichen Schlüssels einer zweiten Ebene, einer ersten Verschlüsselungs-Signatur und einem ersten Satz Software. Sobald das erste Softwareobjekt empfangen wird, Validieren des Zertifikats des öffentlichen Schlüssels der zweiten Ebene mit dem öffentlichen Root-Schlüssel, der ersten Verschlüsselungssignatur mit dem Zertifikat des öffentlichen Schlüssels der zweiten Ebene und des ersten Satzes Software mit der ersten Verschlüsselungssignatur. Wenn der erste Satz Software gültig ist, dann werden das Zertifikat des öffentlichen Schlüssels der zweiten Ebene und der erste Satz Software in dem nichtflüchtigen Speicher gespeichert. Sobald gespeichert, wird ein konsekutives Softwareobjekt mit nur einer konsekutiven Verschlüsselungs-Signatur und einem konsekutiven Satz Software von der Programmierquelle empfangen. Die konsekutive Verschlüsselungs-Signatur wird mit dem gespeicherten Zertifikat des öffentlichen Schlüssels der zweiten Ebene validiert und der konsekutive Satz Software wird mit der konsekutiven Verschlüsselungs-Signatur validiert.
-
DE 10 2012 109 617 A1 offenbart ein System und Verfahren zum Schreiben eines neuen öffentlichen Schlüssels oder eines öffentlichen Ersatzschlüssels in einen Bootloader, der in einem Speichersegment in dem Speicher einer ECU eines Fahrzeugs abgespeichert ist, ohne dass der gesamte Bootloader neu geschrieben werden muss. Das Verfahren beinhaltet das Definieren einer Schlüsseltabelle in dem Bootloader-Speichersegment, welches eine Zahl von vakanten Speicherplätzen beinhaltet, die verfügbar sind, um öffentliche Ersatzschlüssel, wenn diese benötigt werden, zu speichern. Die Schlüsseltabelle ist eine separate Sektion auf dem Bootloader-Speichersegment, so dass die Schlüssel-Tabellen-Speicherplätze nicht von dem Bootloader-Code verwendet werden.
-
Offenbarung der Erfindung
-
Die Erfindung stellt ein Steuergerät, insbesondere ein Motorsteuergerät, sowie ein Verfahren zu dessen Betrieb gemäß den unabhängigen Ansprüchen bereit.
-
Der erfindungsgemäße Ansatz fußt auf der Erkenntnis, dass die Neuprogrammierung (flashing) eines Steuergerätes mit einer aktualisierten Softwareversion - selbst bei deren erwiesener Kompatibilität mit der Hardwareplattform - bei herkömmlichen Steuergeräten oft nur möglich ist, wenn diese Software mit demselben privaten Schlüssel signiert wurde wie die zuvor auf dem Steuergerät gespeicherte Software. Diese Einschränkung ist dem Umstand geschuldet, dass der im Steuergerät hinterlegte und zur Authentifizierung der Software erforderliche öffentliche Schlüssel nach werksseitiger Finalisierung des Steuergerätes zumeist nicht mehr geändert werden kann. Der beschriebene Sachverhalt spielt insbesondere in der kommerziell bedeutsamen Nachserienversorgung (aftermarket) eine wichtige Rolle: Sollen beispielsweise einmal programmierte, jedoch mangels Nachfrage nicht eingesetzte Steuergeräte einem anderen Zweck zugeführt oder ausgediente Geräte wiederaufbereitet werden, so ist dies nach dem Stand der Technik ohne den privaten Schlüssel des Erstausrüsters (original equipment manufacturer, OEM) schwerlich zu bewerkstelligen. Dies führt dazu, dass konventionelle Steuergeräte in den beschriebenen Szenarien für eine Neuprogrammierung insbesondere mit Zielapplikationen eines anderen Herausgebers nicht mehr nutzbar sind und in der Regel nur noch als obsolet entsorgt werden können.
-
Ein Kerngedanke des vorliegend offenbarten Ansatzes besteht somit darin, eine Separation der Ziel-Applikation zum jeweiligen Steuergerät herzustellen. Im Gegensatz zu dem durch
DE 10 2014 208 385 A1 verkörperten nächstliegenden Stand der Technik, welcher von einer gemeinsamen Quelle von Firmware und Anwendungssoftware des Steuergerätes ausgeht, können auf diese Weise Softwarekomponenten verschiedener Herausgeber auf demselben Steuergerät zum Einsatz kommen, die ihre Komponenten marktüblich mit unterschiedlichen privaten Schlüsseln signieren. Ähnlich herkömmlichen Steuergeräten kommt hierbei vorzugsweise ein sogenannter Urlader (bootloader) zum Einsatz, welcher einen dem Steuergerät zugeordneten ersten öffentlichen Schlüssel manipulationssicher verwaltet. Erfindungsgemäß kommt dem Bootloader jedoch eine erweiterte Funktion zu, da er zudem zweite öffentliche Schlüssel der auf dem Steuergerät installierten Softwareapplikationen verwaltet, signiert ablegt, schützt und die Gültigkeit dieser zweiten öffentlichen Schlüssel verifiziert. Diese gegen Überschreiben ungeschützten zweiten öffentlichen Schlüssel können - im Gegensatz zum irreversibel geschützten, dem Steuergerät und dessen Bootloader dauerhaft zugeordneten ersten öffentlichen Schlüssel - auch nach der Finalisierung des Steuergerätes noch ausgetauscht werden, um bestehende Zielapplikationen zu aktualisieren oder gänzlich zu ersetzen.
-
Ein Vorzug dieser nachfolgend beschriebenen Lösung liegt somit in der erfindungsgemäß eröffneten Möglichkeit, Steuergeräte, die mit einem öffentlichen Schlüssel für ihre jeweilige Zielapplikation geschützt sind, neu zu programmieren. Durch diese Fähigkeit wiederum wird ein Austausch der Zielapplikation im Steuergerät auch ohne den privaten Schlüssel des Erstausrüsters in beliebigen Werkstätten ermöglicht. Statt der Zielapplikation wird hierzu erfindungsgemäß der zweite öffentliche Schlüssel der Zielapplikation mit dem ersten privaten Schlüssel des Steuergerätes signiert. Diese lediglich zweistufige Architektur verleiht dem Steuergerät somit eine besondere Flexibilität, ohne jedoch die Komplexität seiner Hardware oder Software übermäßig zu erhöhen.
-
Durch die in den abhängigen Ansprüchen aufgeführten Maßnahmen sind vorteilhafte Weiterbildungen und Verbesserungen des im unabhängigen Anspruch angegebenen Grundgedankens möglich. So kann der Speicher des Steuergerätes in einen ersten Speicherbereich mit Sicherheitsanwendungen, einen zweiten Speicherbereich mit dem Bootloader, einer Vektortabelle und mehreren öffentlichen Schlüsseln sowie einen dritten Speicherbereich mit ebenso vielen Zielapplikationen unterteilt sein. Diese Konfiguration erlaubt es dem Bootloader, den Schlüsseln anhand der Vektortabelle wahlweise eine der Zielapplikationen und Signaturen zuzuordnen, sodass das Steuergerät mit einer Vielzahl von Zielapplikationen unterschiedlicher Erstausrüster programmiert werden mag.
-
Ferner kann das Steuergerät dazu vorkonfiguriert sein, einen ersten öffentlichen Schlüssel samt erster digitaler Signatur von einem externen Trustcenter abzurufen und zumindest diesen ersten öffentlichen Schlüssel zum Schutz des Steuergerätes vor unerlaubter Manipulation unveränderlich im ersten Speicherbereich abzulegen, indem der erste Speicherbereich nach dem Ablegen gegen ein Überschreiben geschützt wird. Auf diese Weise kann ein unabhängiger Zertifizierungsdienstleister oder eine anderweitige vertrauenswürdige Instanz den zur Aktualisierung des Steuergerätes benötigten ersten privaten Schlüssel verwalten.
-
Ferner kann der Bootloader dazu eingerichtet sein, über das Trustcenter mehrmalig die Zielapplikation, den zweiten öffentlichen Schlüssel und die zweite digitale Signatur abzurufen, den im zweiten Speicherbereich abgelegten zweiten öffentlichen Schlüssel durch den abgerufenen zweiten öffentlichen Schlüssel, die im dritten Speicherbereich abgelegte zweite digitale Signatur durch die abgerufene zweite digitale Signatur und die im dritten Speicherbereich hinterlegte Zielapplikation durch die abgerufene Zielapplikation zu ersetzen. Auf diese Weise kann die Zielapplikation gleichsam beliebig oft ersetzt oder um weitere Applikationen ergänzt werden.
-
Ferner kann vorgesehen sein, dass die Vektortabelle nach dem Ersetzen der Zielapplikation neu aufgebaut wird. So können Zielapplikationen unterschiedlicher Anbieter unabhängig voneinander aktualisiert werden, ohne die Funktionsfähigkeit der übrigen Applikationen zu beeinträchtigen.
-
Ferner kann vorgesehen sein, dass der zweite öffentliche Schlüssel und die Vektortabelle innerhalb des zweiten Speicherbereiches vor Schreibzugriffen der Zielapplikationen geschützt sind. Dieses Vorgehen erhöht die Manipulationssicherheit.
-
Ferner kann der Bootloader dazu eingerichtet sein, die ersten öffentlichen Schlüssel der Zielapplikationen anhand des ersten öffentlichen Schlüssels des Steuergerätes zu authentifizieren. Auf diesem Wege entsteht eine lückenlose Vertrauenskette (chain of trust), die ihren Ursprung in der vom Hersteller bescheinigten Identität der Gerätehardware findet.
-
Ferner kann vorgesehen sein, dass der erste Speicherbereich ein erstes digitales Zertifikat, welches den ersten öffentlichen Schlüssel umfasst, und der zweite Speicherbereich ein zweites digitales Zertifikat speichert, welches den zweiten öffentlichen Schlüssel umfasst. Da digitale Zertifikate insbesondere die zu ihrer Prüfung erforderlichen Daten enthalten, können Authentizität und Integrität auf diese Weise durch standardisierte kryptografische Verfahren geprüft werden.
-
Der erste Speicherbereich mag hierbei die Gestalt eines Hardware-Sicherheitsmodules (Hardware security module, HSM) annehmen, welches für eine effiziente Ausführung der Sicherheitsanwendungen bürgt und insbesondere Bootloader und ersten öffentlichen Schlüssel gegen Seitenkanal- und sonstige physische Angriffe schützt.
-
Ferner mag das Steuergerät als Motorsteuergerät ausgebildet sein. Auf diese Weise kann etwa ein Fahrzeug gegen unerlaubte Leistungssteigerungen geschützt werden.
-
Ferner kann ein Verfahren zum Betrieb eines Steuergerätes mit folgenden Merkmalen vorgesehen sein: Anhand von Metadaten des Steuergerätes wird ein asymmetrisches Schlüsselpaar aus dem ersten öffentlichen Schlüssel und einem ersten privaten Schlüssel generiert, die Metadaten und der erste private Schlüssel werden in eine Datenbank außerhalb des Steuergerätes eingetragen und der erste öffentliche Schlüssel wird unveränderlich in einem ersten Speicherbereich des Steuergerätes abgelegt. Dabei können eine für das Steuergerät vorgesehene Zielapplikation mit einer zweiten digitalen Signatur versehen, das Steuergerät mit der Zielapplikation und einem zu der Zielapplikation gehörigen zweiten öffentlichen Schlüssel programmiert werden, der Zielapplikation zugehörige digitale Zertifikate, welche den zweiten öffentlichen Schlüssel umfassen, mit einem zum Steuergerät zugehörigen ersten privaten Schlüssel signiert werden, sodass eine dritte digitale Signatur gebildet wird, und zumindest die digitalen Zertifikate nach dem Signieren zusammen mit der dritten digitalen Signatur in einem zweiten Speicherbereich des Steuergerätes abgelegt werden. Dieses Vorgehen erschließt die vorteilhafte Ersteinrichtung des oben beschriebenen Steuergerätes und ermöglicht dessen einfache Aktualisierung.
-
Ferner kann vorgesehen sein, dass die digitalen Zertifikate nach dem Signieren in einem Trustcenter hinterlegt werden. Auf diese Weise kann ein unabhängiger Zertifizierungsdienstleister oder eine anderweitige vertrauenswürdige Instanz nicht nur die öffentlichen Schlüssel, sondern auch die zu deren Prüfung erforderlichen Daten verwalten.
-
Ferner kann vorgesehen sein, dass das Steuergerät durch eine In-System-Programmierung (in-circuit programming) mit dem Bootloader programmiert wird. Der zu programmierende Schaltkreis muss auf diese Weise nicht mehr aus dem Steuergerät entfernt werden. Letzteres wird so weniger mechanisch belastet und der gesamte Programmiervorgang ist schneller.
-
Schließlich kann vorgesehen sein, dass die Zielapplikation vor einer Ausführung durch den Bootloader in genau zwei Schritten authentifiziert wird. Somit wird gegenüber bekannten Verfahren ein Schritt eingespart.
-
Figurenliste
-
Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert. Es zeigen:
- 1 einen ersten erfindungsgemäßen Speicheraufbau eines Steuergerätes.
- 2 einen zweiten erfindungsgemäßen Speicheraufbau des Steuergerätes.
- 3 die Erstellung und Ablage eines asymmetrischen Schlüsselpaares für das Steuergerät.
- 4 das Softwareupdate einer neuen Zielapplikation mit neuem zweiten öffentlichen Schlüssel.
- 5 den Ablaufplan eines exemplarischen Betriebsverfahrens.
-
Ausführungsformen der Erfindung
-
1 veranschaulicht schematisch den programmierbaren Speicher eines Steuergerätes gemäß einer Ausführungsform der Erfindung, der einen ersten Speicherbereich 10, einen zweiten Speicherbereich 20 sowie einen dritten Speicherbereich 30 umfasst. Der für Sicherheitsanwendungen 11 des Steuergerätes vorgesehene erste Speicherbereich 10 speichert einen dem Steuergerät öffentlich zugeordneten ersten Schlüssel 12. Der zweite Speicherbereich 20 enthält den erfindungsgemäß ausgebildeten Bootloader 21 des Steuergerätes, die dem Steuergerät und dessen Bootloader 21 zugeordnete erste digitale Signatur 22, einen gesicherten Bereich, in welchem wiederum ein den Zielapplikationen 31 des Steuergerätes öffentlich zugeordneter zweiter Schlüssel 23 hinterlegt ist, sowie eine Index-Vektortabelle 24, welche die Zugehörigkeit der jeweils verwendeten Zielapplikation 31 zum jeweiligen zweiten öffentlichen Schlüssel 23 definiert. Die Zielapplikation 31 selbst trägt ihrerseits eine zweite digitale Signatur 32.
-
Es versteht sich, dass die Zielapplikation 31 darüber hinaus eine konventionelle Befehlsvektortabelle (instruction vector table, IVT) oder anderweitige, hier im Einzelnen nicht aufgeführte Datenstrukturen umfassen mag, ohne den Rahmen der Erfindung zu verlassen.
-
Im Zuge des Bootvorganges des Steuergerätes erfolgt zunächst eine Authentifizierung des Bootloaders. Dazu wird ein Streuwert (hash) - zum Beispiel eine Prüfsumme (checksum) - des Bootloaders 21 bestimmt. Zudem wird die dem Bootloader zugeordnete erste digitale Signatur 22 mit dem zugehörigen, unveränderlich hinterlegten ersten öffentlichen Schlüssel 12 entschlüsselt. Sodann wird geprüft, ob der in der ersten digitalen Signatur 22 angegebene Wert dem wie beschrieben gewonnenen Hashwert des Bootloaders 21 entspricht. Ist dies der Fall, so wurde der Bootloader erfolgreich authentifiziert.
-
Für eine durch den erfolgreich authentifizierten Bootloader 21 vorgenommene Authentifizierung der Zielapplikation 31 sind dann lediglich zwei Authentifizierungsschritte durch den Bootloader 21 nötig , nämlich eine erste Authentifizierung des der gemäß der Vektortabelle 24 ausgewählten Zielapplikation 31 zugeordneten zweiten öffentlichen Schlüssels 23 mittels des ersten öffentlichen Schlüssels 12 und eine zweite Authentifizierung der per Vektortabelle 24 ausgewählten Zielapplikation 31 mittels des zugehörigen authentifizierten zweiten öffentlichen Schlüssels 23.
-
Dies ist im Folgenden näher erläutert.
-
Im Falle einer erfolgreichen Authentifizierung des Bootloaders bestimmt die Vektortabelle 24 darüber, welche Zielapplikation 31 im Rahmen des Bootvorganges ausgeführt werden soll. Hierzu wird der im zweiten Speicherbereich 20 hinterlegte zweite öffentliche Schlüssel 23 verwendet und das weitere Validierungsverfahren in Form einer - dem Fachmann als solche hinlänglich bekannten - Signaturüberprüfung eingeleitet, in deren Rahmen der Bootloader 21 anhand des ersten öffentlichen Schlüssels 12 den zweiten öffentlichen Schlüssel 23 authentifiziert. Im Falle des oftmals eingesetzten RSA-Verfahrens würde hierzu beispielsweise anhand des öffentlichen Schlüssels (e, N) der modulare Exponent m ≡ ce mod N der Signatur c berechnet und mit der Zielapplikation bzw. deren Streuwert verglichen. Mit dem solchermaßen authentifizierten zweiten öffentlichen Schlüssel 23 wird die Zielapplikation 31 schließlich anhand ihres Hashwertes authentifiziert.
-
2 beschreibt die Speicherbelegung einer Variante des Steuergerätes, die wahlweise eine von vorliegend zwei Zielapplikationen 31 verschiedener Herausgeber mit entsprechend unterschiedlichen zweiten digitalen Signaturen 32 auszuführen vermag, die gemeinsam im dritten Speicherbereich 30 vorgehalten werden. Der Bootloader 21 verwaltet im zweiten Speicherbereich 20 entsprechend zwei verschiedene zweite öffentliche Schlüssel 23, welche er anhand der folgenden Index-Vektortabelle 24 jeweils eindeutig einer der beiden Zielapplikationen 31 zuordnen kann. Der Begriff „Zielapplikationen“ ist hierbei wie auch in den nachfolgenden Ausführungen stets in einem weiten Sinne zu deuten und umfasst neben reiner Anwendungssoftware beispielsweise unterschiedliche, möglicherweise verschiedenen Betriebssystem-Distributionen zugehörige Betriebssystemkerne (kernels).
-
Eine Zusammenschau der 3 und 4 mit dem Programmablaufplan 51 der 5 verdeutlicht schematisch einen typischen Produktlebenszyklus des Steuergerätes.
-
Die gemäß 3 erfolgende erstmalige Initialisierung eines Steuergerätes 40 sieht die Erstellung (Prozess 52 - 5) eines gerätespezifischen Schlüsselpaares nach dem bekannten Prinzip eines asymmetrischen Kryptosystems oder Public-Key-Verschlüsselungsverfahrens vor. Ein derartiges „asymmetrisches“ Schlüsselpaar besteht aus einem sogenannten privaten und einem öffentlichen Schlüssel, bei welchem es sich vorliegend um den ersten Schlüssel 12 im Sinne der obigen Ausführungen handelt. Beide Schlüssel des Paares werden anhand eines gegebenen Sicherheitsparameters wie einer Zufallszahl üblicherweise mittels einer mathematisch praktisch unumkehrbaren sogenannten Einwegfunktion erzeugt. Das Steuergerät 40 wurde zu diesem Zeitpunkt vorliegend bereits mit dem Softwarecode des Bootloader 21 und ggf. der Sicherheitsanwendungen 11 programmiert. Auch dieser Schritt kann nach einem konventionellen Verfahren wie der sogenannten In-System-Programmierung erfolgen.
-
Das Steuergerät 40 stellt nun eine Anfrage an ein Trustcenter 80 und fordert letzteres auf, das besagte Schlüsselpaar zu generieren. Hierzu werden Metadaten wie eine eindeutige Kennung des Hauptprozessors (central processing unit, CPU) sowie der zur Erzeugung der ersten digitalen Signatur 22 genutzte Hashwert des Bootloaders 21 herangezogen. Das Trustcenter 80 seinerseits generiert sodann das Schlüsselpaar und aus dem dabei erzeugten ersten privaten Schlüssel und dem Hashwert des Bootloaders die erste digitale Signatur 22, trägt die übermittelten Metadaten sowie den erzeugten ersten privaten Schlüssel des Steuergerätes 40 in eine gesicherte Datenbank 90 ein (Prozess 53 - 5) und übergibt dem Steuergerät 40 die erste digitale Signatur 22 und den zugehörigen öffentlichen ersten Schlüssel 12. Letzterer wird schließlich in einem weiteren Bereich des Steuergerätes 40 irreversibel geschützt, z.B. durch Brennen (fusen) des ersten öffentlichen Schlüssels 12 in den ersten Speicherbereich 10 (Prozess 54 - 5).
-
Es sei bemerkt, dass die hier nicht im Einzelnen erörterten Übertragungswege der Daten innerhalb einer Fertigungsumgebung verlaufen und daher gegen Manipulationen geschützt sind.
-
Zum Zwecke eines in 4 exemplarisch dargestellten Software-Updates mit einer neuen Zielapplikation 31 signiert ein Software-Verantwortlicher die aktualisierte Zielapplikation 31 zunächst mit einem zweiten privaten Schlüssel (Prozess 55 - 5), und fügt sie mit der entsprechenden zweiten digitalen Signatur 32 in einem - vorzugsweise der Belegung des dritten Speicherbereiches 30 angepassten - Containerformat zusammen. Die resultierende Containerdatei, also die bereits mit der zweiten digitalen Signatur 32 versehene Zielapplikation 31, und der zugehörige öffentliche zweite Schlüssel 23 werden in einer weiteren Datenbank oder einem anderweitigen Speicher 95 hinterlegt. Die auch hier nicht im Einzelnen erörterten Übertragungswege der Daten verlaufen abermals innerhalb der Fertigungsumgebung und sind daher ebenfalls gegen Manipulationen geschützt.
-
Das in 4 mit dem Bezugszeichen 50 gekennzeichnete Steuergerät stellt nun eine weitere Anfrage an das Trustcenter 80, um eine Neuinstallation der Zielapplikation 31 mit deren neuem zweiten öffentlichen Schlüssel 23 einzuleiten. Der Speicher 95 stellt dem Steuergerät 50 zu diesem Zweck die - in dieser Phase bereits die zweite digitale Signatur 32 tragende - neue Version der Zielapplikation 31 bereit, mit welcher das Steuergerät 50 programmiert wird (Prozess 56 - 5). Zudem übergibt der Speicher 95 dem Trustcenter 80 die zur Zielapplikation 31 zugehörigen digitalen Zertifikat, welche insbesondere den zweiten öffentlichen Schlüssel 23 umfassen. Diese werden mit dem zum Steuergerät 50 zugehörigen ersten privaten Schlüssel aus der Datenbank 90 signiert (Prozess 57 - 5). Zudem wird gegebenenfalls die Vektortabelle 24 im zweiten Speicherbereich 20 anhand des aktualisierten Codeblocks der Zielapplikation 31 durch Eintragung von dessen Adressbereich und etwaigen architekturbedingten Statusregistern neu aufgebaut. Schließlich werden die signierten Zertifikate und die Vektortabelle 24 im dem Bootloader 21 vorbehaltenen zweiten Speicherbereich 20 des Steuergerätes 50 ersetzt (Prozess 58 - 5). Die eigentliche Installation der Zielapplikation 31 durch den Bootloader 21 kann, wie es auch bisher geschah, durch Beschreiben des dritten Speicherbereiches 30 mit dem aktualisierten Codeblock der Zielapplikation 31 erfolgen und - etwa im Rahmen einer fortlaufenden Pflege und Wartung der Software - beliebig oft wiederholt werden. Es versteht sich, dass die neue Zielapplikation hierbei die bereits installierte Zielapplikation 31 auch ergänzen kann und nicht zwingend ersetzen muss.
-
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
-
- DE 102012110559 A1 [0005]
- DE 102012109619 A1 [0006]
- DE 102014208385 A1 [0007, 0011]
- DE 102012109617 A1 [0008]
