DE102012110559A1 - Verfahren und Vorrichtung zum sicheren Herunterladen einer Firmware unter Verwendung eines Diagnoselinkconnectors (DLC) und dem Onstar-System - Google Patents

Verfahren und Vorrichtung zum sicheren Herunterladen einer Firmware unter Verwendung eines Diagnoselinkconnectors (DLC) und dem Onstar-System Download PDF

Info

Publication number
DE102012110559A1
DE102012110559A1 DE102012110559A DE102012110559A DE102012110559A1 DE 102012110559 A1 DE102012110559 A1 DE 102012110559A1 DE 102012110559 A DE102012110559 A DE 102012110559A DE 102012110559 A DE102012110559 A DE 102012110559A DE 102012110559 A1 DE102012110559 A1 DE 102012110559A1
Authority
DE
Germany
Prior art keywords
firmware
vehicle
trusted source
onstar
signed
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102012110559A
Other languages
English (en)
Inventor
Nader M. Rabadi
Kevin M. Baltes
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
GM Global Technology Operations LLC
Original Assignee
GM Global Technology Operations LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by GM Global Technology Operations LLC filed Critical GM Global Technology Operations LLC
Publication of DE102012110559A1 publication Critical patent/DE102012110559A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84—Vehicles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Stored Programmes (AREA)

Abstract

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.

Description

  • HINTERGRUND DER ERFINDUNG
  • 1. Gebiet der Erfindung
  • Diese Erfindung bezieht sich allgemein auf ein System und ein Verfahren zum sicheren Herunterladen von Firmware auf ein Fahrzeug-elektronisches Steuergerät (ECU) und insbesondere auf ein System und ein Verfahren zum sicheren Herunterladen von Firmware auf eine Fahrzeug-ECU, das das Verifizieren, dass die Firmware authentisch ist, durch Validieren der Firmware unter Verwendung zweier separater vertrauenswürdiger Quellen beinhaltet.
  • 2. Diskussion des Standes der Technik
  • Viele moderne Fahrzeuge beinhalten elektronische Steuereinheiten (ECUs), oder Steuergeräte, die den Betrieb der Fahrzeugsysteme, beispielsweise des Antriebsstrang, des Klimasteuersystems, des Infotainment-Systems, der Body-Systeme, der Chassis-Systeme und dergleichen steuern. Diese Steuergeräte benötigen für besondere Zwecke gestaltete Software, d. h. Ausführungscode und Kalibrierungen, 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 vom Gebrauch von Software, die nicht einwandfrei validiert wurde oder die – schlimmer noch – schadhaft entworfen wurde, in einem Fahrzeugsteuergerät, beinhaltet das unbeabsichtigte Verhalten des Fahrzeugs oder seiner Systeme, den Verlust von Antidiebstahl-Eigenschaften auf dem Fahrzeug, das potentielle Herumpfuschen an Komponenten wie beispielsweise dem Kilometerzähler und der Verlust von anderen Fahrzeugmerkmalen und Funktionen.
  • 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 Nachricht 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 Nachricht 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 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 Programmiergerät bereitstellt, welches die Software flashprogrammiert. Der Bootloader flashprogrammiert die Betriebssoftware und Kalibrier-Files in den ECU-Speicher, wobei die Betriebssoftware die Software bereitstellt, die bewirkt, dass verschiedene Fahrzeugfunktionen in Verbindung miteinander arbeiten und die Kalibrier-Files sind die verschiedenen Fahrzeugparameter, wie zum Beispiel Drücke, Temperaturen etc. für die einzelnen Fahrzeugsysteme. Der Bootloader verwendet typischerweise asymmetrische Schlüsselkryptographie und speichert einen öffentlichen Schlüssel, der verwendet werden muss, um eine digitale Signatur zu dekodieren, die von dem hochladenden Computer übermittelt wird, bevor Herunterladen oder neues Flashprogrammieren der ECU gestattet wird, um zu verhindern, dass Schadsoftware oder Kalibrier-Files in die ECU heruntergeladen werden.
  • Bekannte digitale Codiertechniken, wie zum Beispiel die asymmetrische Schlüsselkryptographie, die die oben erwähnten digitalen Signaturen verwendet, sind sehr gut zum Hindern potentieller Hacker am Flashprogrammieren nicht authentischer Software in die ECU. Allerdings können andere Formen von schadhaften Angriffen auf die Firmware, die auf eine Fahrzeug-ECU heruntergeladen werden soll, innerhalb einer Organisation, die Kenntnis über die öffentlichen und privaten Schlüssel hat, herstammen, wobei der potentielle Hacker sich irgendwie Zugang zu den öffentlichen und privaten Schlüsseln verschafft hat, ohne dass er diese entschlüsseln muss.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Im Einklang mit den Lehren der vorliegenden Erfindung werden ein System und ein Verfahren zum Verifizieren, dass Firmware, die auf eine Fahrzeug-ECU heruntergeladen werden soll, authentisch ist, indem zwei separate vertrauenswürdige Quellen zum Verifizieren der Firmware verwendet werden, offenbart. In einer Ausführungsform beinhaltet das Verfahren das Separieren der Firmware in einen ersten Firmware-Teil und einen zweiten Firmware-Teil, und das Signieren des ersten Firmware-Teils mit einem ersten privaten Schlüssel an einer ersten vertrauenswürdigen Quelle. Die erste vertrauenswürdige Quelle hasht den zweiten Firmware-Teil und sendet den gehashten zweiten Firmware-Teil zu einer zweiten vertrauenswürdigen Quelle. Die zweite vertrauenswürdige Quelle signiert den gehashten zweiten Firmware-Teil unter Verwendung eines zweiten privaten Schlüssels und die erste vertrauenswürdige Quelle sendet die Firmware und die Signatur des ersten Firmware-Teils an ein Herunterlade-Werkzeug. Das Fahrzeug fordert die Firmware und die Signatur des ersten Firmware-Teils von dem. Herunterlade-Werkzeug an und fordert die Signatur des zweiten Firmware-Teils von der zweiten vertrauenswürdigen Quelle an. Die zweite vertrauenswürdige Quelle sendet die Signatur des zweiten Firmware-Teils an das Fahrzeug und das Fahrzeug validiert die Signatur des ersten Firmware-Teils unter Verwendung eines ersten öffentlichen Schlüssels und validiert die Signatur des zweiten Firmware-Teils unter Verwendung eines zweiten öffentlichen Schlüssels. Falls beide Teile validiert werden, führt das Fahrzeug die Firmware aus.
  • 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 Systems, das den Betrieb eines Signaturverifizierverfahrens zeigt;
  • 2 ist ein Flussdiagramm, das ein Verfahren zum Authentifizieren eines Firmware-Files, das auf ein Fahrzeug heruntergeladen werden soll, zeigt, wobei das Fahrzeug ein Telematiksystem wie zum Beispiel OnStarTM beinhaltet;
  • 3 ist ein Flussdiagramm, das ein Verfahren zum Authentifizieren eines Firmware-Files, dass auf ein Fahrzeug heruntergeladen werden soll, zeigt, wobei das Fahrzeug nicht mit OnStarTM ausgestattet ist; und
  • 4 ist ein Flussdiagramm, das ein Verfahren zum Authentifizieren eines Firmware-Files, das auf eine Fahrzeug-ECU heruntergeladen werden soll, nur unter Verwendung von OnStarTM zeigt.
  • DETAILLIERTE BESCHREIBUNG DER AUSFÜHRUNGSBEISPIELE
  • Die folgende Diskussion der Ausführungsformen der Erfindung, die auf ein System und ein Verfahren zum Authentifizieren eines Firmware-Files, das auf eine Fahrzeug-ECU heruntergeladen werden soll, durch Validieren der Firmware durch zwei separate vertrauenswürdige Quellen gerichtet ist, ist rein beispielhafter Natur und in keiner Weise dazu gedacht, die Erfindung oder ihre Anwendungen oder Verwendungen einzuschränken. Beispielsweise findet die vorliegende Erfindung eine besondere Anwendung beim Herunterladen von Firmware auf eine Fahrzeug-ECU. Wie Fachleute allerdings leicht erkennen können, kann das Verifizierverfahren eine Anwendung beim Herunterladen von Firmware und/oder Software auf andere Controller finden.
  • 1 ist ein Blockdiagramm 10 eines bekannten Verfahrens zum Verwenden digitaler Signaturen mit einem asymmetrischen Schlüssel zum Authentifizieren von Files, die in Controller programmiert werden sollen. Wie von Fachleuten leicht verstanden werden kann, verwendet die asymmetrische Schlüsselkryptographie ein Paar von mathematisch miteinander in Beziehung stehenden Schlüsseln, welche als ein privater Schlüssel und als ein öffentlicher Schlüssel bekannt sind, um eine Nachricht zu verschlüsseln und zu entschlüsseln. Um eine digitale Signatur zu generieren, verwendet ein Signierer seinen privaten Schlüssel, welcher nur ihm selbst bekannt ist, um ein File zu verschlüsseln. Die digitale Signatur kann später von einem Dritten unter Verwendung des öffentlichen Schlüssels, der mit dem privaten Schlüssel des Signierers zum Authentifizieren eines Files oder einer Nachricht gepaart ist, entschlüsselt werden.
  • In einem Signierschritt 12 wird ein Inhalt-File 14 bereitgestellt, wobei das Inhalt-File 14 ein Stück Software, Firmware, ein Kalibrier-File oder ein anderer Inhalt, der auf einem Controller verwendet werden soll, sein kann. Eine Verschlüsselungs-Hash-Berechnung wird auf dem Inhalt-File 14 ausgeführt, um einen Hash-Wert oder Digest 16 zu generieren. Der Hash-Wert 16 wird dann mit dem privaten Schlüssel des Signierers verschlüsselt, um eine digitale Signatur 18 zu generieren, wobei die digitale Signatur 18 nur für das bestimmte Inhalt-File brauchbar ist.
  • Die digitale Signatur 18 und das Inhalts-File 14 werden dann in einem Verifizierschritt 20 verwendet, der von dem Bootloader in der ECU in der oben diskutierten Anwendung 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 mit den Inhalten des Files 14 programmierten Flash-Speicher 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 eine Gültig-Bestimmung 28 ausgegeben und der mit dem Inhalt-File 14 programmierte Flash-Speicher wird verwendet. Falls der Hash-Wert 22 nicht mit dem berechneten Hash-Wert 24 übereinstimmt, dann wird eine Ungültig-Bestimmung 30 ausgegeben und der mit dem Inhalt-File 14 programmierte Flash-Speicher wird nicht verwendet.
  • Die vorliegende Erfindung schlägt eine Technik zum Verwenden asymmetrischer digitaler Schlüsselsignaturen der oben erwähnten Art zum Verifizieren, dass Firmware, die auf eine Fahrzeug-ECU heruntergeladen werden soll, authentisch ist, vor, wobei das Verfahren das Verifizieren, dass die Firmware authentisch ist, unter Verwendung zweier separater vertrauenswürdiger Quellen, wie zum Beispiel dem Fahrzeughersteller und OnStarTM, wobei jeder die Nachrichten unter Verwendung seiner eigenen privaten Schlüssel signiert, beinhaltet. Die Verbindungen zu dem Fahrzeug können telematische Verbindungen sein, wobei die zwei vertrauenswürdigen Quellen geographisch voneinander getrennte Server sein können, um es schwieriger zu gestalten, die privaten Schlüssel zu kompromittieren, welche zum Erzeugen der digitalen Signaturen verwendet werden.
  • 2 ist ein Flussdiagramm 40, das ein Verfahren zum Verifizieren unter Verwendung zweier separater vertrauenswürdiger Quellen, dass Firmware, die auf eine Fahrzeug-ECU heruntergeladen werden soll, authentisch ist, zeigt. Für die unten geführte Diskussion ist die erste vertrauenswürdige Quelle der Fahrzeughersteller. Sie kann jedoch jede vertrauenswürdige Quelle sein, die das Firmware-File, das heruntergeladen werden soll, bereitstellt, beispielsweis ein Lieferant. Ferner ist, da dies eine von General Motors vorgenommene Patentanmeldung ist, die zweite vertrauenswürdige Quelle OnStarTM. Sie kann jedoch jede andere geeignete vertrauenswürdige Quelle, die von der ersten vertrauenswürdigen Quelle separat ist, sein. In der unten geführten Diskussion wird der Fahrzeughersteller einen privaten Schlüssel MPv und einen öffentlichen Schlüssel MPu haben. OnStarTM wird einen privaten Schlüssel ONPv und einen öffentlichen Schlüssel ONPu haben. Die Firmware ist definiert als FW und kann in zwei Teile, die als FW1 und FW2 definiert sind, gesplittet sein. Eine Hash-Funktion ist definiert als H() und eine Signatur einer Nachricht m unter Verwendung eines privaten Schlüssels p ist definiert als Sig(p, m).
  • In dem Diagramm 40 wird von dem Kasten 42 eine Datenfile-Ablage, in welcher die Firmware FW abgespeichert ist und/oder von der diese erhalten wird, zugewiesen. Die Ablage 42 kann jede geeignete Einrichtung, Server, Ort etc. sein, die dazu in der Lage ist Firmware von einem Fahrzeughersteller, Lieferanten etc. zu empfangen, die Firmware an einem sicheren Ort abzuspeichern und die Firmware in jeder geeigneten Weise, beispielsweise drahtlos, über das Internet, über Telefonleitungen etc. zu übersenden. Es wird angenommen, dass die Datenfile-Ablage 42 die Firmware FW sicher empfängt. Der Kasten 44 stellt eine OnStarTM-Einrichtung dar und ist jede geeignete Einrichtung, die in der Fachwelt bekannte OnStarTM-Operationen bereitstellt, welche in drahtloser Kommunikation mit einem Fahrzeug, welches mit dem Kasten 46 dargestellt ist, sein kann. Obwohl die OnStarTM-Einrichtung 44 als eine der vertrauenswürdigen Quellen in diesem Ausführungsbeispiel verwendet wird, kann von Fachleuten verstanden werden, dass dies als nichteinschränkendes Beispiel gedacht ist und jede geeignete vertrauenswürdige Quelle verwendet werden kann. Kasten 48 stellt ein Werkzeug dar, das verwendet wird, um die Firmware FW auf die ECU auf dem Fahrzeug 46 herunterzuladen. Das Werkzeug 48 kann jedes geeignete computerartige Gerät, das eine Service-Einrichtung, ein Hersteller etc. zur Ausübung dieser Operation verwenden würde, sein. Das Fahrzeug 46 und das Werkzeug 48 würden sich an demselben Ort befinden, wobei das Werkzeug 48 mit dem Fahrzeug 46 über einen Diagnoselinkconnector (DLC), welcher Fachleuten gut bekannt ist, verbunden werden würde.
  • Die Firmware FW wird in der Ablage 42 in erste und zweite Firmware-Teile FW1 und FW2 gesplittet. Die Datenfile-Ablage 42 wird eine Hash-Funktion verwenden, um den ersten Firmware-Teil FW1 zu hashen und dann den gehashten ersten Firmware-Teil FW1 unter Verwendung des privaten Schlüssels MPv des Herstellers zu verschlüsseln, um die Signatur Sig(MPv, H(FW1)) zu erzeugen. Ferner wird die Datenfile-Ablage 42 eine Hash-Funktion verwenden, um den zweiten Firmware-Teil FW2 zu hashen und den gehashten zweiten Firmware-Teil FW2 als eine Nachricht H(FW2) zu der OnStarTM-Einrichtung 44 auf der Leitung 50 zu senden. Der File-Transfer von der Ablage 42 zu der OnStarTM-Einrichtung 44 kann jede geeignete Verbindung, beispielsweise drahtlos oder über die Telefonleitungen, sein. Die OnStarTM-Einrichtung 44 wird den Hash des zweiten Firmware-Teils FW2 unter Verwendung des OnStarTM privaten Schlüssels ONPv signieren, um die Signatur Sig(ONPv, H(FW2)) zu erzeugen. Es wird angemerkt, dass die OnStarTM-Einrichtung 44 nicht die Firmware Files FW, FW1 oder FW2 hat. Es wird ferner angemerkt, dass die Datenfile-Ablage 42 den ersten Firmware-Teil FW1 hashen und signieren wird, den zweiten Firmware Teil FW2 hashen wird und den gehashten zweiten Firmware-Teil H(FW2) an die OnStarTM-Einrichtung 44 zeitnah zu der Zeit, an der die Ablage 42 den Firmware-Teil FW vom Hersteller oder Lieferanten empfängt und bevor die Firmware FW tatsächlich auf die Fahrzeug-ECU heruntergeladen werden muss, senden wird.
  • Die Datenfile-Ablage 42 liefert die Firmware FW und die Signatur Sig(MPv, H(FW1)) an das Werkzeug 48 auf der Leitung 52. Die Verbindung zwischen der Ablage 42 und dem Werkzeug 48 kann jede geeignete Verbindung für die hier diskutierten Zwecke sein, beispielsweise eine Telematikverbindung, eine Internetverbindung etc. Wenn das Werkzeug 48 mit dem Fahrzeug 46 durch den DLC für das Herunterladen der Firmware FW verbunden ist, lädt das Werkzeug 48 die Firmware FW und die Signatur Sig(MPV, H(FW1)), die sie empfangen und von der Datenfile-Ablage 42 auf der Leitung 54 abgespeichert hat, herunter. Die Ablage 42 kann die Firmware FW und den gehashten und signierten ersten Firmware-Teil FW1, der auf das Werkzeug 48 gespeichert werden soll, bereitstellen, bevor das Fahrzeug 46 anfordert, dass dieser heruntergeladen werden muss. Es kann wünschenswert sein, dass das Fahrzeug 46 ein Passwort, was mit dem Bezugszeichen 56 dargestellt wird, in die ECU eingeben muss, welches den ordnungsgemäßen Benutzer des Fahrzeugs 46 identifiziert, bevor mit dem Firmware-Herunterladen fortgefahren wird. Die Passworteingabe an das Werkzeug 48 kann ausgeführt werden, bevor die Firmware FW und die Signatur Sig(MPv, H(FW1)) auf das Fahrzeug 46 heruntergeladen werden.
  • Das Fahrzeug 46 fordert dann über die OnStarTM-Telematikverbindung die Signatur des zweiten Firmware-Teils FW2 auf der Leitung 58 an und die OnStarTM-Einrichtung 44 liefert die Signatur Sig(MPv, H(FW2)) an das Fahrzeug 46 auf der Leitung 60. Um die Firmware FW, die von dem Werkzeug 48 geliefert wird, zu akzeptieren, wird die ECU auf dem Fahrzeug 46 die Firmware FW durch Validieren der Signatur Sig(MPv, H(FW1)) unter Verwendung des öffentlichen Schlüssels MPu des Herstellers und durch Validieren der Signatur Sig(ONPv, H(FW2)) der OnStarTM-Einrichtung 44 unter Verwendung des öffentlichen Schlüssels ONPu von OnStarTM validieren. Falls beide Teile der Nachricht validiert werden, lässt die ECU es zu, dass die Firmware FW auf dem Fahrzeug 46 ausgeführt wird.
  • Obwohl bei der oben geführten Diskussion die Firmware FW in die zwei Teile FW1 und FW2 separiert wird, könnte dieses Erfordernis für Berechnungszwecke ziemlich komplex sein. In einer alternativen Ausführungsform wird die Firmware FW nicht separiert sondern das ganze Stück Firmware FW wird in der Datenfile-Ablage 42 gehasht, um an die OnStarTM-Einrichtung 44 gesendet zu werden. Das ganze Stück Firmware FW wird unter Verwendung des privaten Schlüssels MPv des Herstellers in der Datenfile-Ablage 42 signiert, um die Signatur Sig(MPv, H(FW)) zu erzeugen. Die OnStarTM-Einrichtung 44 wird den Hash des Firmware-Teils FW unter Verwendung des privaten Schlüssels ONPv von OnStarTM signieren, um die Signatur Sig(ONPv, H(FW)) zu erzeugen.
  • 3 ist ein Flussdiagramm 70, das ein anderes Verfahren zum Validieren der Firmware FW, die auf eine Fahrzeug-ECU heruntergeladen werden soll, zeigt, die die gleichen Einrichtungen und Elemente aus dem Diagramm 40 aufweist, bei der das Fahrzeug 46 jedoch kein OnStarTM-Teilnehmer ist und demzufolge nicht in der Lage ist, Signaturen direkt von der OnStarTM-Einrichtung 44 zu empfangen. Die Datenfile-Ablage 42 hasht wie oben den zweiten Firmware-Teil FW2 und sendet diesen zu der OnStarTM-Einrichtung 44 auf der Leitung 50, wobei die OnStarTM-Einrichtung 44 den Hash-Wert unter Verwendung des privaten Schlüssels ONPv von OnStarTM signiert. Da die OnStarTM-Einrichtung 44 die Signatur des zweiten Firmware-Teils FW2 nicht an das Fahrzeug 46 senden kann, sendet die OnStarTM-Einrichtung 44 die Signatur des zweiten Firmware-Teils FW2 an die Datenfile-Ablage 42 auf der Leitung 72. Die Datenfile-Ablage 42 hat nun sowohl den signierten ersten Firmware-Teil Sig(MPv, H(FW1)) als auch den signierten zweiten Firmware-Teil Sig(ONPv, H(FW2)) von der OnStarTM-Einrichtung 44 und liefert diese Nachrichten und die Firmware FW auf Anfrage an das Werkzeug 48. Das Werkzeug 48 lädt dann die gesamte Firmware FW und Signaturen auf der DLC-Leitung 54 herunter, wobei die ECU in dem Fahrzeug 46 die zwei Signaturen separat unter Verwendung des öffentlichen Schlüssels MPu des Herstellers und des öffentlichen Schlüssels ONPu von OnStarTM validiert, um die Firmware FW zu validieren.
  • 4 ist ein Flussdiagramm 80 ähnlich zu den Flussdiagrammen 40 und 50, wobei ähnliche Elemente und Einrichtungen mit den gleichen Bezugszeichen versehen sind. In dieser Ausführungsform wird das Werkzeug 48 nicht dazu verwendet, die Firmware FW auf das Fahrzeug 46 herunterzuladen, sondern die Firmware FW wird direkt von der OnStarTM-Einrichtung 44 heruntergeladen. Die Datenfile-Ablage 42 liefert die Firmware FW, den zweiten Firmware-Teil FW2 und den signierten ersten Firmware-Teil Sig(MPv, H(FW1)) an die OnStarTM-Einrichtung 44 über die Leitung 50. In dieser Ausführungsform hasht die Ablage 42 nicht den zweiten Firmware-Teil FW2 sondern liefert ihn mit dem gesamten Firmware-File FW. Die OnStarTM-Einrichtung 44 hasht zuerst und signiert dann den Hash des zweiten Firmware-Teils FW2 unter Verwendung des privaten Schlüssels ONPv von OnStarTM, um die Signatur Sig(ONPv, H(FW2)) zu berechnen. Falls die Firmware FW von der OnStarTM-Einrichtung 44 auf das Fahrzeug 46 heruntergeladen werden soll, werden die gesamte Firmware FW, die Signatur des ersten Firmware-Teils Sig(MPv, H(FW1)) und die Signatur des zweiten Firmware-Teils Sig(ONPv, H(FW2)) telematisch an das Fahrzeug 46 auf der Leitung 82 übersandt, welches jede Signatur separat validiert, um die Authentizität der Firmware FW zu verifizieren.
  • Wie von Fachleuten gut verstanden wird, können verschiedene oder einige Schritte und Verfahren, die hier erörtert wurden, um die Erfindung zu beschreiben, von einem Computer, einem Prozessor oder einer anderen elektronischen Recheneinheit ausgeführt werden, die mit Hilfe elektrischer Phänomene Daten manipuliert und/oder transformiert. Diese Computer und elektrischen Geräte können verschiedene flüchtige und/oder nicht flüchtige Speicher inklusive einem festen computerlesbaren Medium mit einem darauf befindlichen ausführbaren Programm beinhalten, das verschiedene Codes oder ausführbare Instruktionen beinhaltet, die von dem Computer oder Prozessor ausgeführt werden, wobei der Speicher und/oder das computerlesbare Medium alle Formen und Arten von einem Speicher und anderen computerlesbaren Medien beinhalten kann.
  • Die vorhergehende Diskussion zeigt und beschreibt rein exemplarische Ausführungsbeispiele der vorliegenden Erfindung. Ein Fachmann kann leicht aus der Diskussion an den beigefügten Figuren und Patentansprüchen erkennen, dass zahlreiche Änderungen, Modifikationen und Variationen gemacht werden können, ohne dabei den Geist und den Bereich der Erfindung zu verlassen, wie er mit den folgenden Patentansprüchen definiert ist.

Claims (10)

  1. Ein Verfahren zum Authentifizieren eines Stücks von Firmware, das auf einen Controller heruntergeladen werden soll, wobei das Verfahren umfasst: – Signieren der Firmware oder eines ersten Teils der Firmware mit einem ersten privaten Schlüssel in einer ersten vertrauenswürdigen Quelle; – Signieren der Firmware oder eines zweiten Teils der Firmware mit einem zweiten privaten Schlüssel in einer zweiten vertrauenswürdigen Quelle; – Validieren der signierten Firmware oder des ersten Teils der Firmware unter Verwendung eines ersten öffentlichen Schlüssels in dem Controller; – Validieren der Firmware oder des zweiten Teils der Firmware unter Verwendung eines zweiten öffentlichen Schlüssels in dem Controller; und – Authentifizieren der Firmware für den Gebrauch falls die Firmware oder der erste Teil der Firmware durch den ersten öffentlichen Schlüssel in dem Controller validiert wird und die Firmware oder der zweite Teil der Firmware durch den zweiten öffentlichen Schlüssel in dem Controller validiert wird.
  2. Verfahren nach Anspruch 1, des Weiteren umfassend das Hashen der Firmware oder des ersten Teils der Firmware bevor die Firmware oder der erste Teil der Firmware signiert wird und das Hashen der Firmware oder des zweiten Teils der Firmware bevor die Firmware oder der zweite Teil der Firmware signiert wird, und wobei das Signieren der Firmware oder des ersten Teils der Firmware mit einem ersten privaten Schlüssel das Signieren des Hashs der Firmware oder des ersten Teils der Firmware und das Signieren der Firmware oder des zweiten Teils der Firmware mit einem zweiten privaten Schlüssel das Signieren des Hashs der Firmware oder des zweiten Teils der Firmware beinhaltet.
  3. Verfahren nach Anspruch 1, wobei das Signieren der Firmware oder des zweiten Teils der Firmware mit einem zweiten privaten Schlüssel in einer zweiten vertrauenswürdigen Quelle das Bereitstellen der zu signierenden Firmware von einer Datenfile-Ablage an die zweite vertrauenswürdige Quelle beinhaltet.
  4. Verfahren nach Anspruch 3, des Weiteren umfassend das Zurückkehren der signierten Firmware oder des zweiten Teils der Firmware von der zweiten vertrauenswürdigen Quelle zurück zu der Datenfile-Ablage.
  5. Verfahren nach Anspruch 4, des Weiteren umfassend das Bereitstellen der Firmware, der signierten Firmware oder des ersten Teils der Firmware und der signierten Firmware oder des zweiten Teils der Firmware von der Datenfile-Ablage an ein Herunterlade-Werkzeug.
  6. Verfahren nach Anspruch 1, des Weiteren umfassend das Bereitstellen der signierten Firmware oder des ersten Teils der Firmware an ein Herunterlade-Werkzeug von der ersten vertrauenswürdigen Quelle und das Bereitstellen der signierten Firmware oder des zweiten Teils der Firmware an den Controller von der zweiten vertrauenswürdigen Quelle.
  7. Verfahren nach Anspruch 1, des Weiteren umfassend das Bereitstellen der Firmware oder des zweiten Teils der Firmware und der signierten Firmware oder des ersten Teils der Firmware von der ersten vertrauenswürdigen Quelle an die zweite vertrauenswürdige Quelle und das Bereitstellen der Firmware, der signierten Firmware oder des zweiten Teils der Firmware und der signierten Firmware oder des ersten Teils der Firmware von der zweiten vertrauenswürdigen Einrichtung an den Controller.
  8. Verfahren nach Anspruch 1, des Weiteren umfassend das Bereitstellen eines Passworts an den Controller vor dem Herunterladen der Firmware.
  9. Verfahren nach Anspruch 1, wobei die erste vertrauenswürdige Quelle ein Fahrzeughersteller ist.
  10. Verfahren nach Anspruch 9, wobei die zweite vertrauenswürdige Quelle OnStarTM ist.
DE102012110559A 2011-12-15 2012-11-05 Verfahren und Vorrichtung zum sicheren Herunterladen einer Firmware unter Verwendung eines Diagnoselinkconnectors (DLC) und dem Onstar-System Pending DE102012110559A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/327,216 2011-12-15
US13/327,216 US8856536B2 (en) 2011-12-15 2011-12-15 Method and apparatus for secure firmware download using diagnostic link connector (DLC) and OnStar system

Publications (1)

Publication Number Publication Date
DE102012110559A1 true DE102012110559A1 (de) 2013-06-20

Family

ID=48522203

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102012110559A Pending DE102012110559A1 (de) 2011-12-15 2012-11-05 Verfahren und Vorrichtung zum sicheren Herunterladen einer Firmware unter Verwendung eines Diagnoselinkconnectors (DLC) und dem Onstar-System

Country Status (3)

Country Link
US (1) US8856536B2 (de)
CN (1) CN103166759B (de)
DE (1) DE102012110559A1 (de)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102018211139A1 (de) 2018-07-05 2020-01-09 Robert Bosch Gmbh Steuergerät sowie Verfahren zu dessen Betrieb
DE102020216380A1 (de) 2020-12-21 2022-06-23 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Betreiben eines Steuergeräts, auf dem mehrere Applikationen ausgeführt werden
DE102023000563B3 (de) 2023-02-20 2024-02-01 Mercedes-Benz Group AG Informationstechnisches-System, Fahrzeug und Verfahren zum Einbringen einer Aktualisierung auf ein Zielsystem

Families Citing this family (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5435022B2 (ja) * 2011-12-28 2014-03-05 株式会社デンソー 車載システム及び通信方法
US8966248B2 (en) 2012-04-06 2015-02-24 GM Global Technology Operations LLC Secure software file transfer systems and methods for vehicle control modules
EP2883219A1 (de) * 2012-08-09 2015-06-17 Technische Universität Dortmund Verfahren zur sicherstellung der funktionssicherheit in der elektromobilität mittels digitaler zertifikate
CN103346886B (zh) * 2013-07-01 2016-12-28 天地融科技股份有限公司 一种发送签名数据的方法和电子签名令牌
US9548867B2 (en) * 2013-11-26 2017-01-17 Rockwell Automation Technologies, Inc. Method and apparatus for secure distribution of embedded firmware
WO2015129352A1 (ja) * 2014-02-28 2015-09-03 日立オートモティブシステムズ株式会社 認証システム、車載制御装置
US9542558B2 (en) 2014-03-12 2017-01-10 Apple Inc. Secure factory data generation and restoration
US9436456B2 (en) * 2014-04-17 2016-09-06 Myine Electronics, Inc. System and method for management of software updates at a vehicle computing system
US9722781B2 (en) 2014-07-09 2017-08-01 Livio, Inc. Vehicle software update verification
DE102015203776A1 (de) * 2015-03-03 2016-09-08 Robert Bosch Gmbh Verfahren zur Programmierung eines Steuergeräts eines Kraftfahrzeugs
DE102015209116A1 (de) 2015-05-19 2016-11-24 Robert Bosch Gmbh Verfahren und Aktualisierungsgateway zum Aktualisieren eines eingebetteten Steuergerätes
DE102015209108A1 (de) 2015-05-19 2016-11-24 Robert Bosch Gmbh Verfahren und Entscheidungsgateway zum Autorisieren einer Funktion eines eingebetteten Steuergerätes
US10706140B2 (en) 2016-03-30 2020-07-07 Ford Global Technologies, Llc Vehicle computer update authentication
US11321072B2 (en) 2016-03-30 2022-05-03 Ford Global Technologies, Llc Vehicle computer update authentication
US9923722B2 (en) * 2016-04-18 2018-03-20 GM Global Technology Operations LLC Message authentication library
US10171478B2 (en) * 2016-06-30 2019-01-01 Faraday & Future Inc. Efficient and secure method and apparatus for firmware update
US11146401B2 (en) 2016-08-10 2021-10-12 Ford Global Technologies, Llc Software authentication before software update
EP3291087A1 (de) * 2016-09-01 2018-03-07 Nxp B.V. Vorrichtung und zugehöriges verfahren zur authentifizierung von firmware
CN107273150B (zh) * 2017-05-10 2020-10-02 深圳市金百锐通信科技有限公司 预加载固件下载写入方法及装置
US10594666B2 (en) 2017-12-19 2020-03-17 Micron Technology, Inc. Secure message including a vehicle private key
US10871952B2 (en) * 2017-12-20 2020-12-22 Nio Usa, Inc. Method and system for providing secure over-the-air vehicle updates
US10430178B2 (en) 2018-02-19 2019-10-01 GM Global Technology Operations LLC Automated delivery and installation of over the air updates in vehicles
CN108920962B (zh) * 2018-06-26 2020-06-26 百富计算机技术（深圳）有限公司 固件下载验签方法、固件发布方法、移动终端及服务器
CN109446815B (zh) * 2018-09-30 2020-12-25 华为技术有限公司 基本输入输出系统固件的管理方法、装置和服务器
KR20200119601A (ko) * 2019-04-10 2020-10-20 현대모비스 주식회사 차량의 바이너리 데이터 처리 장치 및 방법
US11366879B2 (en) * 2019-07-08 2022-06-21 Microsoft Technology Licensing, Llc Server-side audio rendering licensing
CN112422595B (zh) * 2019-08-20 2022-10-11 华为技术有限公司 车载系统安全保护方法及设备
CN111142906B (zh) * 2019-12-25 2023-11-10 浙江大华技术股份有限公司 一种设备固件升级方案迭代的方法、装置与设备
CN112632562B (zh) * 2020-12-28 2024-01-26 四川虹微技术有限公司 设备启动方法、设备管理方法和嵌入式设备

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6601212B1 (en) 2000-03-29 2003-07-29 Hewlett-Packard Development Company, Lp. Method and apparatus for downloading firmware to a non-volatile memory
US7069452B1 (en) * 2000-07-12 2006-06-27 International Business Machines Corporation Methods, systems and computer program products for secure firmware updates
US20050065678A1 (en) 2000-08-18 2005-03-24 Snap-On Technologies, Inc. Enterprise resource planning system with integrated vehicle diagnostic and information system
ATE492085T1 (de) * 2003-01-28 2011-01-15 Cellport Systems Inc Ein system und ein verfahren zum steuern des zugriffs von anwendungen auf geschützte mittel innerhalb eines sicheren fahrzeugtelematiksystems
US7225065B1 (en) 2004-04-26 2007-05-29 Hti Ip, Llc In-vehicle wiring harness with multiple adaptors for an on-board diagnostic connector
US20060143600A1 (en) 2004-12-29 2006-06-29 Andrew Cottrell Secure firmware update
US20070061597A1 (en) * 2005-09-14 2007-03-15 Micky Holtzman Secure yet flexible system architecture for secure devices with flash mass storage memory
US20080027602A1 (en) 2006-05-30 2008-01-31 Yeap Tet H System and method for deterring theft of vehicles and other products having integral computer means
KR20080039046A (ko) 2006-10-31 2008-05-07 삼성전자주식회사 펌웨어 업데이트 장치 및 방법
US20090119657A1 (en) 2007-10-24 2009-05-07 Link Ii Charles M Methods and systems for software upgrades
CN101247416A (zh) 2008-03-25 2008-08-20 中兴通讯股份有限公司 基于ota的固件下载方法、预处理方法、完整性验证方法
US20090258642A1 (en) 2008-04-11 2009-10-15 Ease Diagnostics Vehicle communication system
CN101299849B (zh) * 2008-04-25 2010-05-12 中兴通讯股份有限公司 一种WiMAX终端及其启动方法
US20090327741A1 (en) 2008-06-30 2009-12-31 Zimmer Vincent J System and method to secure boot uefi firmware and uefi-aware operating systems on a mobile internet device (mid)
US20100130160A1 (en) 2008-11-24 2010-05-27 Delphi Technologies Inc. Vehicle emergency communication device and method for utilizing the vehicle emergency communication device
CN101447012B (zh) * 2008-12-22 2012-08-29 华为终端有限公司 一种电子设备和电子设备中固件的验证方法
CN101610499A (zh) 2009-07-13 2009-12-23 中兴通讯股份有限公司 无线数据卡的升级方法和系统
US8838332B2 (en) 2009-10-15 2014-09-16 Airbiquity Inc. Centralized management of motor vehicle software applications and services
CN101795454B (zh) * 2010-02-10 2012-10-10 熊文俊 基于移动通信独立通道的双身份认证方法及系统
US8903354B2 (en) 2010-02-15 2014-12-02 Ford Global Technologies, Llc Method and system for emergency call arbitration
KR20110108071A (ko) 2010-03-26 2011-10-05 삼성전자주식회사 펌웨어 다운로드 시스템

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102018211139A1 (de) 2018-07-05 2020-01-09 Robert Bosch Gmbh Steuergerät sowie Verfahren zu dessen Betrieb
DE102020216380A1 (de) 2020-12-21 2022-06-23 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Betreiben eines Steuergeräts, auf dem mehrere Applikationen ausgeführt werden
WO2022136083A1 (de) 2020-12-21 2022-06-30 Robert Bosch Gmbh Verfahren zum betreiben eines steuergeräts, auf dem mehrere applikationen ausgeführt werden
DE102023000563B3 (de) 2023-02-20 2024-02-01 Mercedes-Benz Group AG Informationstechnisches-System, Fahrzeug und Verfahren zum Einbringen einer Aktualisierung auf ein Zielsystem

Also Published As

Publication number Publication date
CN103166759B (zh) 2016-12-07
CN103166759A (zh) 2013-06-19
US8856536B2 (en) 2014-10-07
US20130159717A1 (en) 2013-06-20

Similar Documents

Publication Publication Date Title
DE102012110559A1 (de) Verfahren und Vorrichtung zum sicheren Herunterladen einer Firmware unter Verwendung eines Diagnoselinkconnectors (DLC) und dem Onstar-System
DE102012109619A1 (de) Verfahren zum Bereitstellen einer digitalen Signatur zum Sichern einer Flash-Programmierfunktion
DE102013105042A1 (de) Sicheres Flashprogrammieren eines sekundären Prozessors
DE102013108021A1 (de) Verfahren zum selektiven Software-Rollback
DE102013108020A1 (de) Authentifizierungsschema zum Aktivieren eines Spezial-Privileg-Modus in einem gesicherten elektronischen Steuergerät
DE102013108022A1 (de) Verfahren zum Aktivieren des Entwicklungsmodus eines gesicherten elektronischen Steuergeräts
DE10008974B4 (de) Signaturverfahren
US8966248B2 (en) Secure software file transfer systems and methods for vehicle control modules
DE102012109615B4 (de) Verwendung eines Manifests zur Präsenzaufzeichnung von gültiger Software und Kalibrierung
DE102016205289A1 (de) Verfahren, Prozessor und Gerät zur Integritätsprüfung von Nutzerdaten
DE102012109617A1 (de) Verfahren zum Ersetzen eines öffentlichen Schlüssels eines Bootloaders
DE102015209108A1 (de) Verfahren und Entscheidungsgateway zum Autorisieren einer Funktion eines eingebetteten Steuergerätes
DE102013205051A1 (de) Aktualisieren eines digitalen Geräte-Zertifikats eines Automatisierungsgeräts
DE102012215729A1 (de) System und Verfahren zum Authentisieren mehrerer Dateien unter Verwendung einer getrennten digitalen Signatur
US20140058532A1 (en) Method for partial flashing of ecus
DE102017208503A1 (de) Verfahren, Computerlesbares Medium, System und Fahrzeug umfassend das System zum Bereitstellen eines Datensatzes eines Fahrzeugs an einen Dritten
EP3654222B1 (de) Fahrzeug, netzwerkkomponente, verfahren, computerprogramm und vorrichtung zum generieren einer kennung für einen ausrüstungszustand eines fahrzeugs
DE102016221108A1 (de) Verfahren zum Aktualisieren einer Software eines Steuergeräts eines Fahrzeugs
WO2017102295A1 (de) Verfahren und sicherheitsmodul zum bereitstellen einer sicherheitsfunktion für ein gerät
DE102010038179B4 (de) Individuelle Aktualisierung von Computerprogrammen
WO2022008201A1 (de) Verfahren zur erweiterten validierung eines containerabbilds
DE102018217431A1 (de) Sicherer Schlüsseltausch auf einem Gerät, insbesondere einem eingebetteten Gerät
DE102020117552A1 (de) Sichere hybrid-boot-systeme und sichere boot-verfahren für hybridsysteme
DE112020001126T5 (de) Fahrzeugsteuergerät
DE102018211139A1 (de) Steuergerät sowie Verfahren zu dessen Betrieb

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication
R082 Change of representative

Representative=s name: SCHWEIGER, MARTIN, DIPL.-ING. UNIV., DE