DE102022126459A1

DE102022126459A1 - Authentifizierung von softparts für ein elektronisches steuergerät

Info

Publication number: DE102022126459A1
Application number: DE102022126459.9A
Authority: DE
Inventors: Brian Farrell
Original assignee: GM Global Technology Operations LLC
Current assignee: GM Global Technology Operations LLC
Priority date: 2022-03-17
Filing date: 2022-10-12
Publication date: 2023-09-21
Also published as: US20230297663A1; CN116805899A

Abstract

Ein Verfahren und ein System zur Authentifizierung von Softpart-Aktualisierungen für ein elektronisches Steuergerät (ECU) oder ein anderes Verarbeitungsgerät ist vorgesehen Die Authentifizierung kann beinhalten, dass ein Backoffice Authentifizierungsdaten an ein Programmiertool liefert, woraufhin das Steuergerät mit dem Programmiertool interagiert, um die Softpart-Aktualisierungen zu authentifizieren. Die Authentifizierung kann optional das Feststellen durch das Steuergerät umfassen, ob die Softpart-Aktualisierung in Übereinstimmung mit verschiedenen Arten von Authentifizierungen authentifiziert werden soll.

Description

EINLEITUNG
Die vorliegende Offenbarung bezieht sich auf die Authentifizierung von Softpart-Aktualisierungen, wie beispielsweise unter anderem die Authentifizierung von Aktualisierungen für Softparts, die in einem elektronischen Steuergerät (ECU) eines Fahrzeugs enthalten sind.
Ein elektronisches Steuergerät (ECU) kann als Computer, Mikrocontroller oder anderes Verarbeitungselement betrachtet werden, das dazu ausgelegt ist, einen oder mehrere Vorgänge, Funktionen, Prozesse usw. einem abhängigen System bereitzustellen oder dieses anderweitig zu unterstützen, z. B. durch Ausgabe entsprechender Signale, Daten, Steuerungen und dergleichen. Steuergeräte sind in vielen Fällen eigenständige Geräte, die dazu bestimmt sind, ein abhängiges System regelmäßig zu betreiben, z. B. um wiederholt Informationen, Messungen, Werte, Eingaben usw. zu analysieren, um entsprechende Ausgaben an das abhängige System zu tätigen und es zu steuern, und in einigen Fällen, z. B. wenn ein abhängiges System nicht direkt gesteuert wird, die Informationen usw. an ein anderes Steuergerät oder ein anderes Element zu liefern. Die zugrunde liegende Komponentenausstattung eines Steuergeräts kann variieren; in vielen Fällen wird jedoch davon ausgegangen, dass sie einen Prozessor enthalten, der Funktionen entsprechend den in einem Speicher gespeicherten nicht transitorischen Befehlen ausführt, d. h. die Befehle stellen die Software oder andere Logik dar, die verwendet wird, um den gewünschten Betrieb, die gewünschte Funktion usw. zu ermöglichen.
Steuergeräte und dergleichen können als ein fest verbundenes oder ortsfestes System betrachtet werden, wenn sie in Anwendungen eingesetzt werden, bei denen die mit ihnen durchgeführten Vorgänge während des gesamten Lebenszyklus des Systems relativ gleich oder ähnlich sein sollen. Solche Steuergeräte können innerhalb des Host-Gerätes so eingesetzt werden, dass sie begrenzt zugänglich sind oder sich an Orten befinden, die typischerweise nicht für Benutzerinteraktionen zugänglich sind, so dass sie demzufolge möglicherweise keine Benutzerschnittstellen oder Mensch-Maschine-Schnittstellen (HMI) aufweisen. Solche Steuergeräte können stattdessen auf drahtgebundene oder drahtlose Verbindungen gestützt sein, z. B. über ein Netzwerk oder eine andere Kommunikation, um die Interaktion mit anderen Steuergeräten, Vorrichtungen, Sensoren, abhängigen Systemen usw. zu erleichtern. Bei Verwendung in einem Fahrzeug, z. B. einem Automobil, können verschiedene Steuergeräte beispielsweise als Motorsteuermodul (ECM), Telematikeinheit (TU), Antriebsstrangsteuermodul (PCM), Getriebesteuermodul (TCM), Bremsensteuermodul (BCM), zentrales Steuermodul (CCM), ein zentrales Zeitsteuermodul (CTM), ein Beifahrertürmodul (PDM), ein Systemsteuermodul (SCM), ein Airbag-Steuermodul (ACM), ein Batteriemanagementsystem (BMS), ein allgemeines Elektronikmodul (GEM), ein Bordnetzsteuergerät (BSG), ein Aufhängungssteuermodul (SCM) und mehr.
Die Steuergeräte können regelmäßig Aktualisierungen erfordern, die im Falle der erwähnten zum Einsatz in Kraftfahrzeugen bestimmten Steuergeräten mit Aktualisierungen des Designs, Kalibrierungsänderungen, neuen oder geänderten Funktionen und anderen Änderungen verbunden sein können, die typischerweise mit dem Ändern von Software, Code, Firmware, Datensätzen, Dateien und dergleichen einhergehen. Diese Merkmale oder Konstrukte können als Softparts bezeichnet werden, da unter Softparts im Allgemeinen solche Merkmale verstanden werden. Dementsprechend können sich einige Aktualisierungen auf das Ändern von Code oder Software zum Ändern einer Funktion beziehen, während sich andere Aktualisierungen auf das Anpassen von Kalibrierungstabellen, das Hinzufügen von Daten für Suchfunktionen oder das Überarbeiten von Informationswerten beziehen, denen vertraut wird, ohne dass sie notwendigerweise mit einer Änderung der Funktionalität einhergehen. Die Wege und Verfahren, mit denen Steuergeräte untereinander und mit anderen Elementen kommunizieren, um Softparts zu aktualisieren oder anderweitige betriebliche Änderungen vorzunehmen, können je nach Implementierung variieren und richten sich häufig nach den Standards und Protokollen des Host-Geräts.
Unified Diagnostic Services (UDS) ist, zumindest bei einigen Kraftfahrzeugen, ein häufig verwendetes Diagnose-Kommunikationsprotokoll zum Ermöglichen der Aktualisierung von Automobilelektronik wie einem Steuergerät. Die Internationale Organisation für Normung unterhält eine Norm für UDS mit dem Titel ISO 14229-1 Straßenfahrzeuge - Einheitliche Diagnosedienste (UDS), die hiermit durch Bezugnahme in vollem Umfang einbezogen ist. Ein wertvoller Aspekt von UDS ist ein Dienst, der auf die Verhinderung oder Vereitlung von nicht ordnungsgemäß authentifizierten Aktualisierungen durch unerwünschte Akteure abzielt. Die Dienstkennung (SID), die mit dem entsprechenden Sicherheitszugriff verbunden ist, wird in der Regel in Bezug auf die Request-SID 0x27 und die Antwort-SID 0x67 angegeben, die sich auf eine Request-Antwort-Strategie bezieht, die auf einem Seed (Zufallszahl) beruht. Die Strategie ermöglicht einen Authentifizierungsprozess, bei dem ein Steuergerät einen Seed erzeugt und an ein Programmiertool sendet, das diesen daraufhin verwendet, um einen Schlüssel zu erzeugen und an das Steuergerät zurückzusenden. Das Steuergerät authentifiziert dann das Programmiertool, um Aktualisierungen im Steuergerät vorzunehmen, je nachdem, ob der zurückgesendete Schlüssel, d.h. der Schlüssel des Programmiertools, mit dem Schlüssel des Steuergeräts übereinstimmt. UDS authentifiziert zumindest auf diese Weise effektiv den Zugang des Akteurs zum Steuergerät, wodurch dieser die Erlaubnis zur Vornahme von Aktualisierungen erhält, sofern er einen passenden Schlüssel vorweisen kann.
KURZDARSTELLUNG
Hierin werden ein Authentifizierungsverfahren und -system zur Authentifizierung von Aktualisierungen von Softparts offengelegt, indem beispielsweise ein Programmiertool oder anderes Element, das Softparts eines Steuergeräts oder einer anderen Steuereinheit zu aktualisieren versucht, nicht nur Zugang zu einem Softpart-Signatursystem oder einem Softpart-Signaturschlüssel, d. h. einem für ein Steuergerät vertrauenswürdigen Schlüssel haben muss, sondern zusätzlich auch Authentifizierungen durchführen muss, die darauf abzielen, dass von einer vertrauenswürdigen Stelle oder einem vertrauenswürdigen Dienst bereitgestellte Softpart-Aktualisierungen bei der Implementierung im Steuergerät unverändert bleiben. Die vorgesehenen Authentifizierungsfunktionen tragen dazu bei, dass ein autorisierter Softpart-Anbieter, z. B. ein Erstausrüster (OEM), bei der Aktualisierung von Softparts den Zugang zu Steuergeräten sichern kann, so dass die Aktualisierungen auf autorisierte Softparts beschränkt sind und die Wahrscheinlichkeit verringert wird, dass ein unerwünschter Akteur Änderungen vornimmt oder anderweitig in die Aktualisierungen eingreift.
Ein Verfahren zur Authentifizierung einer Softpart-Aktualisierung für ein elektronisches Steuergerät (ECU) wird offenbart. Das Verfahren umfasst das Bestimmen von Sendeschlüsselinformationen, die in einer von einem Programmiertool an das Steuergerät übertragenen Sendeschlüsselabfrage enthalten sind, und das Bestimmen auf Grundlage der Sendeschlüsselinformationen, ob die Softpart-Aktualisierung gemäß einer ersten oder einer zweiten Authentifizierungsart zu authentifizieren ist. Das Steuergerät kann dazu ausgelegt sein, sowohl die erste als auch die zweite Art von Funktionen auszuführen. Die erste Art ermöglicht es dem Steuergerät, eine Aktualisierung bei Abschluss einer Authentifizierung des Entsperrschlüssels durchzuführen. Die zweite Art ermöglicht es dem Steuergerät, eine Aktualisierung bei Authentifizierung eines für den Softpart erstellten Message-Digest durchzuführen, zusätzlich zum Abschluss einer Authentifizierung des Entsperrschlüssels.
Das Verfahren kann die Aufforderung an das Steuergerät umfassen, eine Challenge-Authentifizierung durchzuführen, um zu ermitteln, ob die Aktualisierung nach der ersten oder der zweiten Art zu authentifizieren ist, z. B. um die Authentifizierung bei erfolgloser Challenge-Authentifizierung nach der ersten Art und nach erfolgreicher Challenge-Authentifizierung nach der zweiten Art durchzuführen.
Das Verfahren kann das Feststellen umfassen, dass die Challenge-Authentifizierung erfolgreich ist, wenn das Steuergerät sowohl einen Challenge-Message-Authentifizierungscode (MAC) als auch einen Antwort-MAC erzeugt und mit den entsprechenden Challenge- und Antwort-MACs abgleicht, die in den Sendeschlüsselinformationen enthalten sind.
Das Verfahren kann die Aufforderung an das Steuergerät umfassen, den Challenge-MAC durch Signieren einer Challenge mit einem Entsperrschlüssel zu erzeugen und optional die Challenge durch Setzen eines höchstwertigen Bits einer Unterfunktion vor der Verkettung der Unterfunktion mit einem Seed zu erzeugen, nachdem das Steuergerät den Seed durch Verkettung einer Steuergerätekennung (ID) mit einer Zufallszahl erzeugt hat. Das Steuergerät kann den Antwort-MAC durch Signieren einer ersten Konstante mit einem Einmalschlüssel erzeugen.
Das Verfahren kann den Abgleich von nicht mehr als x höchstwertigen Bits des mit dem Steuergerät erzeugten Challenge-MAC mit dem in den Sendeschlüsselinformationen enthaltenen Challenge-MAC sowie den Abgleich von nicht mehr als y höchstwertigen Bits des mit dem Steuergerät erzeugten Antwort mit dem in den Sendeschlüsselinformationen enthaltenen Antwort umfassen; beispielsweise kann x 16 und y 12 sein, so dass die 16 höchstwertigen Bits des Challenge-MAC und die 12 höchstwertigen Bits des Antwort abgeglichen werden.
Das Verfahren kann die Aufforderung an das Steuergerät umfassen, nach der Challenge-Authentifizierung und vor der Aktualisierung des Softparts jeweils eine Daten- und eine Modulauthentifizierung durchzuführen.
Das Verfahren kann das Feststellen umfassen, dass die Datenauthentifizierung abgeschlossen ist, wenn das Steuergerät einen Daten-MAC erzeugt und mit einem entsprechenden Daten-MAC abgleicht, die in einer zusätzlichen Authentifizierungsanforderung enthalten ist, wobei die zusätzliche Authentifizierungsanforderung nach der Challenge-Authentifizierung von dem Programmiertool an das Steuergerät übertragen wird.
Das Verfahren kann die Aufforderung an das Steuergerät umfassen, den Daten-MAC durch Signieren des Message Digest mit einem gemeinsamen Geheimnis zu erzeugen. Der Message Digest kann in den Sendeschlüsselinformationen enthalten sein und zuvor durch Verarbeitung des Softparts nach einem Algorithmus erzeugt werden.
Das Verfahren kann dementsprechend die Bestimmung umfassen, dass die Modulauthentifizierung als abgeschlossen gilt, wenn das Steuergerät die mit dem Programmiertool identifizierten Modul-IDs auf Übereinstimmung mit den darauf enthaltenen Modul-IDs verifiziert und vor Aktualisierung des Softparts optional eine Signatur des Softparts verifiziert, wobei die Signatur mit den Sendeschlüsselinformationen gesendet wird.
Das Verfahren kann beinhalten, dass die Authentifizierung des Entsperrschlüssels voraussetzt, dass in dem Steuergerät ein Entsperrschlüssel gespeichert ist, der mit einem in den Sendeschlüsselinformationen enthaltenen Entsperrschlüssel übereinstimmt.
Ein Verfahren zur Authentifizierung einer Softpart-Aktualisierung für ein elektronisches Steuergerät (ECU) eines Kraftfahrzeugs wird offenbart. Das Verfahren kann entsprechend der von einem Programmiertool an das Steuergerät übertragenen Informationen die Authentifizierung der Softpart-Aktualisierung in Reaktion auf die Verifizierung eines Entsperrschlüssels und einer Message Digest des Softparts durch das Steuergerät umfassen, wobei der Entsperrschlüssel und das Message Digest in den Informationen enthalten sind und das Message Digest dem Programmiertool von einem Backoffice zur Authentifizierung der Softpart-Aktualisierung bereitgestellt wird.
Das Verfahren kann die Bestimmung des zu verifizierenden Message Digest durch das Steuergerät umfassen, wenn ein damit verbundener und in den Informationen enthaltener Message-Authentifizierungscode (MAC) mit einem entsprechenden, von dem Steuergerät erzeugten MAC übereinstimmt.
Ein System zur Authentifizierung eines Softparts für ein elektronisches Steuergerät (ECU) eines Kraftfahrzeugs wird offenbart. Das System kann ein Backoffice enthalten, das zur Erzeugung eines Message Digest und einer Signatur für den Softpart ausgelegt ist; das Backoffice kann beispielsweise den Message Digest und die Signatur in Reaktion auf die Überprüfung der Authentizität einer Softpart-Aktualisierung erzeugen. Das System kann ein Programmiertool enthalten, das dazu ausgelegt ist, den Message Digest und die Signatur zusammen mit den dem Steuergerät zur Verfügung gestellten Informationen zu senden, wobei das Steuergerät auf Grundlage der Informationen über die Verifizierung der Aktualisierung entscheidet.
Das Programmiertool kann einen Entsperrschlüssel und einen Message-Authentifizierungscode (MAC) für den in den Informationen enthaltenen Message Digest umfassen, auf deren Grundlage das Steuergerät die Verifizierung der Aktualisierung feststellt, wenn der MAC, die Signatur und der Entsperrschlüssel mit einem lokal vom Steuergerät festgelegten MAC, Signatur und Entsperrschlüssel übereinstimmen.
Die obigen Merkmale und Vorteile sowie weitere Merkmale und damit verbundene Vorteile dieser Offenbarung sind aus der folgenden detaillierten Beschreibung beispielhafter Ausgestaltungen und Verfahren zur Realisierung der vorliegenden Offenbarung leicht ersichtlich, wenn sie in Verbindung mit den beigefügten Zeichnungen und den im Anhang aufgeführten Ansprüchen betrachtet werden. Darüber hinaus schließt diese Offenbarung ausdrücklich Kombinationen und Unterkombinationen der vor- und nachstehend dargelegten Elemente und Merkmale ein.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Die beigefügten Zeichnungen, die als Bestandteile in diese Beschreibung aufgenommen sind, veranschaulichen Ausführungen der Offenbarung und dienen zusammen mit der Beschreibung zur Erläuterung der Grundsätze der Offenbarung.

1 zeigt ein System zur Authentifizierung von Softpart-Aktualisierungen gemäß einem nicht einschränkenden Aspekt der vorliegenden Offenbarung.
2a-b veranschaulichen schematisch ein Diagramm, das einem Verfahren zur Authentifizierung von Softpart-Aktualisierungen gemäß einem nicht einschränkenden Aspekt der vorliegenden Offenbarung zugeordnet ist.

Die beigefügten Zeichnungen sind nicht notwendigerweise maßstabsgetreu und können eine etwas vereinfachte Darstellung verschiedener Merkmale der vorliegenden Offenbarung darstellen, wie sie hierin offenbart sind, so zum Beispiel bestimmte Abmessungen, Ausrichtungen, Positionen und Formen. Die Einzelheiten dieser Merkmale werden zum Teil durch den jeweiligen Verwendungszweck und die Einsatzumgebung bestimmt.
DETAILLIERTE BESCHREIBUNG
Die vorliegende Offenbarung kann in vielen verschiedenen Formen ausgestaltet werden. Repräsentative Beispiele sind in den verschiedenen Zeichnungen dargestellt und werden hier im Detail als nicht-einschränkende Darstellungen der offenbarten Grundsätze beschrieben. Demzufolge sollten Elemente und Beschränkungen, die in den Abschnitten „Zusammenfassung“, „Einleitung“, „Kurzdarstellung“ und „Detaillierte Beschreibung“ beschrieben, aber nicht ausdrücklich in den im Anhang aufgeführten Ansprüchen aufgeführt sind, weder einzeln noch gemeinsam unausgesprochen, durch Rückschluss oder auf andere Weise in die Ansprüche aufgenommen werden. Wenn nicht ausdrücklich anders angegeben, schließt darüber hinaus die Verwendung des Singulars den Plural ein und umgekehrt, sind die Begriffe „und“ und „oder“ sowohl verbindend als auch trennend, bedeuten die Begriffe „eine/r/s“ und „alle“ „jegliche und alle“ und die Begriffe „einschließlich“, „enthaltend“, „umfassend“, „mit“ und dergleichen „einschließlich ohne Einschränkung“.
Begriffe der Annäherung wie „ungefähr“, „annähernd“, „im Wesentlichen“, „im Allgemeinen“, „circa“ usw. können hier im Sinne von „bei, nahe an oder fast an“ oder „innerhalb von 0-5% von“ oder „innerhalb akzeptabler Fertigungstoleranzen“ oder logischen Kombinationen davon verwendet werden. Wie hierin verwendet, ist ein Bauteil, das „dazu ausgelegt ist“, eine bestimmte Funktion auszulegen, in der Lage, diese in unverändertem Zustand auszuführen, anstelle nur über das Potenzial zu verfügen, die bestimmte Funktion nach weiteren Änderungen auszuführen. Anders gesagt, die beschriebene Hardware ist, wenn sie ausdrücklich zur Ausführung der angegebenen Funktion ausgelegt ist, konkret für die Ausführung der angegebenen Funktion ausgewählt, erstellt, realisiert, verwendet, programmiert und/oder entworfen. Räumlich relative Begriffe wie „innere“, „äußere“, „unterhalb“, „unter“, „untere“, „über“, „obere“ und dergleichen können hierin der Einfachheit halber verwendet werden, um die Beziehung eines Elements oder Merkmals zu einem oder mehreren anderen Elementen oder Merkmalen zu beschreiben, wie in den Figuren der Zeichnungen veranschaulicht. Räumlich relative Begriffe können dazu bestimmt sein, zusätzlich zu der in den Figuren der Zeichnungen dargestellten Ausrichtung unterschiedliche Ausrichtungen des in Gebrauch oder Betrieb befindlichen Geräts oder Systems einzuschließen.
Unter Bezugnahme auf die Zeichnungen, in denen gleiche Bezugszeichen auf gleiche oder ähnliche Komponenten in den einzelnen Figuren Bezug nehmen, zeigt 1 ein System 10 zur Authentifizierung von Softpart-Aktualisierungen gemäß einem nicht einschränkenden Aspekt der vorliegenden Offenbarung. Das System wird in erster Linie im Hinblick auf die Erleichterung von Aktualisierungen für ein elektronisches Steuergerät (ECU) 12 beschrieben, das beispielhaft in einem Kraftfahrzeug enthalten ist, da die vorliegende Offenlegung die Verwendung und Anwendung des Systems auch zur Sicherung von Aktualisierungen für andere Geräte als Steuergeräte und zur Aktualisierung von Geräten außerhalb des Automobilbereichs vorsieht. Das System 10 arbeitet hauptsächlich auf der Grundlage von Interaktionen zwischen einem Programmiertool 14, einem Backoffice 16 und dem Steuergerät 12, wobei durch deren Zusammenarbeiten die Authentifizierung von Softpart-Aktualisierungen gemäß den hierin vorgesehenen Verfahren und Methodiken ermöglicht wird. Auch wenn nicht im Detail gezeigt, kann jeder Akteur einen Prozessor enthalten, der dazu ausgelegt ist, nicht-transitorische Befehle in einem enthaltenen Speicher auszuführen, um die verschiedenen hierin beschriebenen Vorgänge, Funktionen und Aktivitäten zu ermöglichen, und ebenso kann jeder Akteur geeignete Schnittstellen, Verbindungen, Kommunikationsfähigkeiten usw. umfassen, die zur Umsetzung derselben erforderlich sind.
Das Backoffice 16 kann als vertrauenswürdige Instanz betrachtet werden, z. B. eine Instanz unter Kontrolle oder Leitung eines Erstausrüsters (OEM), die mit der Validierung von Softparts für die Aktualisierung beauftragt ist. Die zu aktualisierenden Softparts können von internen und/oder externen Quellen 20 bereitgestellt und zur Validierung an ein Softpart-Freigabesystem 22 geliefert werden. Die Validierung kann darin bestehen, dass ein Administrator entscheidet, ob das Softpart für eine Aktualisierung geeignet ist, was optional die Identifizierung der für die entsprechende Aktualisierung vorgesehenen Steuergeräte sowie der Modul-IDs und anderer zur Koordinierung der Installation erforderlicher Informationen umfassen kann. Das Softpart-Freigabesystem 22 kann eine Datenbank enthalten, die in der Lage ist, Softparts mit Steuergerätekennungen (IDs) und Modul-IDs zu speichern und querzuvergleichen, so dass das Freigabesystem 22 effektiv eine aktuelle Version der für jedes Steuergerät 12 autorisierten Softparts aufrechterhalten kann. Jeder Softpart kann aus Steuergeräte-IDs, Modul-IDs, Teilenummern usw. bestehen oder diesen anderweitig zugeordnet sein, um deren Verwendung mit Dateien, Datensätzen oder anderen Inhalten zu koordinieren, die die Software, den Code, die Programmierung usw. enthalten, aus denen der Softpart besteht, d. h., die in das Steuergerät 12 zu programmierenden Informationen können in einer entsprechenden Datei oder Struktur enthalten sein, die an das Steuergerät 12 übertragen und von diesem verarbeitet werden kann, um nach Abschluss der hierin vorgesehenen Authentifizierung die Installation auf dem Steuergerät zu ermöglichen.
Wie dargestellt, umfasst das Backoffice 16 Sicherheitsmerkmale, die mit einem Softpart-Signatursystem 24 und einem Steuergerät-Entsperr-Sicherheitsserver 26 verbunden sind. Das Signatursystem 24 und der Sicherheitsserver 26 können zusammenarbeiten, um die Sicherung der Authentifizierungsmaßnahmen zur Authentifizierung der zu aktualisierenden Softparts zu ermöglichen. In den Sicherheitsmaßnahmen können Informationen zur Freigabe verschiedener kryptographischer Prozesse und Manipulationen gespeichert werden, einschließlich Fähigkeiten zur Verwendung von Schlüsseln, Hashing-Algorithmen, Medienauthentifizierungscodes (MACs), gemeinsamen Geheimnissen usw. Das Freigabesystem 22 kann verwendet werden, um einen Message Digest für jeden Softpart zu erzeugen, der dann dem Sicherheitsserver 26 zur Verfügung gestellt wird, um Verifizierungsdaten (z. B. MAC) gemäß einem gemeinsamen Geheimnis zu erzeugen, das jedem für dessen Empfang vorgesehenen Steuergerät 12 bekannt ist, z. B. durch Verkettung und anschließende Signatur der Message-Digests und der zugehörigen Softpart-Nummern und der Modul-IDs mit dem gemeinsamen Geheimnis. Dadurch wird sichergestellt, dass der Sicherheitsserver 26 dem Steuergerät 12 zusätzliche Authentifizierungsdaten von Softparts zur Verfügung stellt, die im Freigabesystem 22 zur offiziellen Freigabe freigegeben wurden. Auf diese Weise kann das Steuergerät 12 selbst dann, wenn ein Unbefugter Zugang zum Signatursystem 24 oder zu den vom Signatursystem 24 verwendeten Softpart-Signaturschlüsseln erhält, erkennen, dass die bereitgestellte Softpart-Aktualisierung nicht authentisch ist. Der Sicherheitsserver 26 kann für die Verfolgung von Entsperrschlüsseln, gemeinsamen Geheimnissen und Ähnlichem verantwortlich sein und ist beispielhaft als vom Signatursystem 24 getrennt dargestellt, lediglich um einen Aspekt der vorliegenden Offenbarung hervorzuheben, bei dem die jedem Steuergerät 12 zugeordneten Schlüssel, Geheimnisse usw. vom Softpart-Signatursystem 24 getrennt gehalten werden können. Diese Zweiteilung kann hilfreich sein, um die Integration des Softpart-Freigabesystems 22 in bestehende Steuergerätesicherheitssysteme 26 zu ermöglichen, so dass die vorliegende Offenbarung in bestehende Steuerstrukturen integriert werden kann. Der Sicherheitsserver 26 kann mit dem Freigabesystem 22 und/oder dem Signatursystem 24 interagieren, um ihnen Schlüssel, gemeinsame Geheimnisse und andere Informationen darüber zum Zwecke der Erzeugung des Message Digest und anderer Datensätze zu liefern.
Das Programmiertool 14 kann mit dem Sicherheitsserver 26 und/oder anderen Elementen des Backoffice 16 interagieren, um die Authentifizierung von Softparts mit dem Steuergerät 12 zu ermöglichen. Das Programmiertool 14 kann einem Gerät entsprechen, das über ausreichende Fähigkeiten verfügt, um mit dem Steuergerät 12 zu interagieren. Das Programmiertool 14 kann beispielsweise einem eigenständigen Prüfgerät entsprechen, das an ein Netzwerk oder direkt an das Steuergerät 12 angeschlossen werden kann, z. B. kann das Prüfgerät bei Nutzung in einem Kraftfahrzeug an ein Fahrzeugnetzwerk angeschlossen werden, das mit dem Steuergerät 12 kommuniziert, und/oder das Prüfgerät kann direkt an eine Buchse oder Schnittstelle des Steuergeräts 12 angeschlossen werden. Das Programmiertool 14 kann optional kein eigenständiges Prüfgerät sein, sondern in einem Modul oder einem anderen Steuergerät des Geräts enthalten sein, dessen Steuergerät ein Softpart-Aktualisierung benötigt, z.B. kann ein Steuergerät als Programmiertool für ein anderes Steuergerät dienen. Das Programmiertool 14 kann sich auch entfernt von dem Gerät mit dem Steuergerät 12 befinden, um z. B. drahtlose oder OTA (over-the-air)-Aktualisierungen zu ermöglichen. Das Programmiertool 14 kann zum Ermöglichen der Interaktion mit einem Administrator eine Benutzerschnittstelle oder eine Mensch-Maschine-Schnittstelle (HMI) enthalten, wenn dies für die Eingabe von Informationen und Befehlen hinsichtlich von benutzerabhängigen Aspekten zum Ermöglichen der Aktualisierung erforderlich ist.
Das Programmiertool 14 kann ein generischer Gegenstand oder nicht spezifisch für das Steuergerät 12 oder das Gerät sein, insofern als es das Hochladen von Informationen, Dateien und andere Daten darauf erfordern kann. Eine Utility-Datei 28 kann enthalten sein, um dem Programmiertool 14 die gewünschten oder spezifischen Informationen zur Verfügung zu stellen, z.B. kann die Utility-Datei 28 eine Kopie der mit den Softparts verbundenen Software, Kalibrierungstabellen, Kodierung usw. enthalten, d.h. die Datensätze, die dem Steuergerät 12 zur Aktualisierung zur Verfügung gestellt werden sollen, sowie andere Informationen, um die hierin vorgesehene Authentifizierung zu ermöglichen. Die Utility-Datei 28 kann auf dem Programmiertool 14 gespeichert oder ihm auf andere Weise zur Verfügung gestellt werden, z. B. vom Backoffice 16 über drahtgebundene oder drahtlose Kommunikation. Ein Aspekt der vorliegenden Offenbarung sieht die Verwendung des Programmiertools 14 durch Fahrzeugtechniker oder -besitzer vor, während sie an dem Gerät arbeiten oder sich anderweitig in einem Umfeld befinden, in dem sie mit dem Programmiertool 14 interagieren müssen, während das Programmiertool außer Reichweite ist oder nicht mit dem Backoffice 16 kommuniziert. Dies kann erreicht werden, indem das Programmiertool 14 zusammen mit Utility-Datei 28 im Voraus geladen wird, so dass es anschließend für das Gerät mit dem Steuergerät 12 verwendet werden kann. Natürlich mag es nicht wünschenswert sein, dass ein separates Programmiertool 14 erforderlich ist oder das Programmiertool 14 im Voraus geladen werden muss, insbesondere wenn der Umfang der drahtlosen Kommunikation zunimmt, so dass einige oder alle hier beschriebenen Interaktionen mittels drahtgebundener oder drahtloser Nachrichtenübermittlung direkt zwischen dem Backoffice 16 und dem Steuergerät 12 erfolgen können.
2a-b veranschaulichen schematisch ein Diagramm 30 im Zusammenhang mit einem Verfahren zur Authentifizierung von Softpart-Aktualisierungen gemäß einem nicht einschränkenden Aspekt der vorliegenden Offenbarung. Das Verfahren und die entsprechenden dem Backoffice 16, Programmiertool 14 und Steuergerät 12 zugeordneten Infrastrukturen werden hauptsächlich beispielhaft in Bezug auf zumindest einige der mit dem UDS-Sicherheitszugriff einhergehenden Nachrichtenübermittlungsaktivitäten und Interaktionen beschrieben. Insbesondere werden verschiedene Nachrichten, Antworten, Anforderungen, Prozesse und Sequenzen nicht einschränkend in Bezug auf UDS und die Anfrage SID 0x27 und die Antwort SID 0x67 beschrieben, da die vorliegende Offenlegung ihre Verwendung und Anwendung mit anderen Protokollen und Standards und hauptsächlich in Bezug auf andere Sequenzen und Arten von Nachrichtenübermittlung, Kommunikation usw. in Betracht zieht. UDS wird dementsprechend lediglich als Referenzrahmen für eine Art von häufig verwendetem Sicherheitsprotokoll vorgestellt, das von den hier beschriebenen zusätzlichen Authentifizierungsmaßnahmen profitieren und in Zusammenarbeit mit diesen verwendet werden kann.
Es wird gezeigt, dass eine Teilenummerauthentifizierung 34 erfolgt, indem das Programmiertool 14 eine Teilenummer-Anforderung 36 an das Steuergerät 12 sendet und das Steuergerät 12 daraufhin eine Teilenummer-Antwort 38 zurücksendet. Die Teilenummer-Antwort 38 kann eine 16-Bit-Steuergeräte-ID und eine Auflistung der auf dem Steuergerät 12 gespeicherten Softpartnummern und Modul-IDs enthalten, d.h. eine Auflistung aller darauf arbeitenden Softparts. Jeder Version des Softparts kann eine neue Teilenummer zugewiesen werden, so dass sich die Softpartnummer mit jeder Version ändert und die Modul-IDs konstant bleiben können. Die Übereinstimmung der Modul-IDs kann bei der Identifizierung von Speicherpartitionen auf dem Steuergerät 12 und anderen Informationen im Zusammenhang mit der Speicherung und Verwendung der darin enthaltenen Softparts vorteilhaft und hilfreich sein. Die Teilenummern-Antwort 38 kann dementsprechend eine Auflistung der Softpartnummern mit Querverweisen auf die entsprechenden Modul-IDs enthalten, z. B. in Form einer Datei oder einer Nachschlagetabelle.
Das Programmiertool 14 kann die von dem Steuergerät 12 gelieferten Softpartnummern mit den in der Utility-Datei 28 identifizierten Softparts vergleichen, um Softparts auf dem Steuergerät 12 zu identifizieren, die aktualisiert werden müssen. Von der Notwendigkeit einer Aktualisierung eines Softparts kann ausgegangen werden, wenn eine neue Softpartnummer, z. B. eine neue Version, verfügbar ist, wenn sich beispielsweise die Programmierung oder der damit verbundene Code ändert und/oder wenn Kalibrierungsdateien oder andere Informationen hinzugefügt oder anderweitig mit der Software verbunden werden sollen. Ein Softpart kann auch als aktualisierungsbedürftig angesehen werden, wenn das Softpart in dem Steuergerät 12 fehlt oder nicht ordnungsgemäß funktioniert. Eine Softpart-Aktualisierung kann mit einer gewünschten Änderung der Software, des Codes, der unterstützenden Dateien oder Tabellen und anderer Informationen einhergehen, die auf dem Steuergerät 12 gespeichert sind und mit dessen Betrieb zusammenhängen.
In Reaktion auf das Feststellen eines oder mehrerer zu aktualisierender Softparts kann das Programmiertool 14 einen Sicherheitszugriff auf das Steuergerät 12 initiieren, optional auf die in UDS beschriebene Weise, wobei das Programmiertool 14 eine 0x27-Seed-Anforderung 40 ausgibt. Die Seed-Anforderung 40 kann das Steuergerät 12 dazu veranlassen, einen Seed 42 zu erzeugen und diesen anschließend in einer Antwort 44 an das Programmiertool 14 zu übermitteln. Der Seed 42 kann von dem Steuergerät 12 durch Verkettung einer 16-Bit-ECU-ID mit einer 15-Bit-Zufallszahl erzeugt werden, die ebenfalls von dem Steuergerät 12 erzeugt werden kann. Die Steuergerät-ID kann eine eindeutige Kennung für das Steuergerät 12 sein, und die Zufallszahl kann ein 15-Bit-Wert sein, der als Sicherheitsmaßnahme verwendet wird, um sicherzustellen, dass ein zuvor ausgegebener Seed nicht wiederverwendet wird. Ein Wert anstelle einer Zufallszahl kann optional verwendet werden, wenn der Wert unbekannt oder einen ausreichenden Schutz vor einem Relay-Angriff bietet.
Obwohl eine Challenge-Authentifizierung 46 (siehe 2b) vor oder ohne Erhalt der Softpartnummern eingeleitet werden kann, kann sie durchgeführt werden, nachdem das Programmiertool 14 den Seed 42 erhalten hat. Die Challenge-Authentifizierung 46 kann verwendet werden, um die Art der für die Aktualisierung von Softparts erforderlichen Authentifizierung festzulegen. Die vorliegende Offenbarung sieht die Anwendung mehrerer Authentifizierungsstufen und -verfahren vor, wobei beispielhaft ohne beschränkende Wirkung eine erste Art und eine zweite Art der Authentifizierung beschrieben werden. Die in Folge näher beschriebene erste Art der Authentifizierung kann einer Seed-basierten Anforderung-Antwort-Strategie entsprechen, bei der das Steuergerät 12 nach abgeschlossener Authentifizierung des Entsperrschlüssels eine Programming-Session für Softpart-Aktualisierungen autorisiert, d.h. nach Erhalt eines Entsperrschlüssels, der im Programmiertool 14 oder im Backoffice 16 aus dem Seed 42 abgeleitet wurde, und nach der Verifizierung, dass das Softpart mit einer gültigen digitalen Signatur verbunden ist, die durch den Softpart-Signaturschlüssel erstellt wurde, der dem Signatursystem 24 zugeordnet ist. Die zweite Art der Authentifizierung kann einer robusteren Strategie entsprechen, bei der das Steuergerät 12 eine zusätzliche Authentifizierung über die Verifizierung des Entsperrschlüssels und der Signatur hinaus durchführen muss, d.h. indem das Programmiertool 14 dem Steuergerät auch ein Softpart mit einem gültigen, vom Signatursystem 24 erstellten Message Digest zur Verfügung stellt.
Die Challenge-Authentifizierung 46 kann beinhalten, dass das Programmiertool eine Challenge 48 durch Verkettung einer Unterfunktion mit dem Seed 42 erzeugt. Die Unterfunktion kann verwendet werden, um eine Sicherheitsfreigabe oder eine Sicherheits-Session für die Aktualisierung zu identifizieren. Die Unterfunktion kann auf diese Weise beispielsweise dazu verwendet werden, eine Berechtigung des Programmiertools und insbesondere dessen Benutzers zur Durchführung bestimmter Aktualisierungen am Steuergerät 12 zu identifizieren. Eine beispielhafte Challenge 48 ist nachstehend dargestellt.

Subfunction [1] ECU_ID [16] Random Number [15]
Es können verschiedene Berechtigungsebenen zur Verfügung stehen, um die Art der Aktualisierungen festzulegen, die das Programmiertool 14 vornehmen darf, was von seinem Benutzer abhängig sein kann, z. B. kann eine Berechtigung auf Werksebene mehr Änderungen am Steuergerät 12 erlauben als eine Berechtigung auf Verbraucherebene. Ein nicht einschränkender Aspekt der vorliegenden Offenbarung sieht eine Berechtigung auf Händlerebene vor, wodurch ein Techniker oder Mechaniker eines Autohauses in der Lage sein kann, Aktualisierungen am Steuergerät 12 vorzunehmen, die weniger bedeutend sind als diejenigen, die in einem Werk oder am Herstellungsort des Steuergeräts 12 vorgenommen werden können, aber bedeutender als diejenigen, die von einem Verbraucher oder Eigentümer des Geräts mit dem Steuergerät 12 vorgenommen werden könnten.
Eine Challenge-Anforderung oder Nachricht 52 mit der Challenge 48 und optional den zu aktualisierenden Softpartnummern kann vom Programmiertool 14 an das Backoffice 16 für eine Authentifizierungsanalyse 54 übermittelt werden. Die Analyse 54 kann beinhalten, dass das Backoffice 16 die Softpartnummern verwendet, um die zu aktualisierenden Softparts und die dazugehörige(n) Message Digest und Modul-ID(s) zu identifizieren. Die Analyse 54 kann die Unterfunktion auch verwenden, um festzustellen, ob das Programmiertool 14 berechtigt ist, bestimmte Aktualisierungen vorzunehmen, z. B. kann das Backoffice 16 den Message Digest oder andere dem Programmiertool 14 zur Verfügung gestellten Aktualisierungsinformationen entsprechend der mit der Unterfunktion verbundenen Berechtigungsebene filtern oder einschränken, so dass einige Aktualisierungen ganz verhindert oder entsprechend der Berechtigungsebene eingeschränkt werden können. Die Analyse 54 kann auch die Feststellung beinhalten, ob eine erste oder zweite Art der Authentifizierung für die Aktualisierung der Softparts erforderlich ist. Es kann vorteilhaft sein, wenn das Backoffice 16 bestimmen kann, ob die Authentifizierung von der ersten oder der zweiten Art sein soll, damit deren Verwendung selektiv bestimmt werden kann, z. B. entsprechend den Fähigkeiten des Steuergeräts 12, den mit dem Programmiertool 14 einhergehenden Berechtigungen und/oder abhängig davon, ob der zugehörige Softpart den mit dem Softpart-Freigabesystem 22 verbundenen Validierungsprozess abgeschlossen hat.
Der Analyseprozess 54 kann beinhalten, dass ein höchstwertiges Bit der in der Challenge 48 enthaltenen Unterfunktion auf 1 gesetzt wird, wenn die zweite Art der Authentifizierung erforderlich ist, und dass das höchstwertige Bit auf 0 belassen wird, wenn die erste Art der Authentifizierung erforderlich ist. Die derartige Einstellung des höchstwertigen Bits wird als Gestaltungsparameter betrachtet, der darauf beruht, dass die Unterfunktion typischerweise eine Anzahl von Nullen am Anfang enthält, so dass ihre Einstellung von 0 auf 1 effektiv ein Nicht-Ereignis ist, das keinen Einfluss auf die mit der Unterfunktion identifizierte Sicherheitsstufe hat. Während andere Mechanismen verwendet werden können, um zu bestimmen, ob eine Aktualisierung gemäß der ersten oder zweiten Art der Authentifizierung durchgeführt werden soll, kann das derartige Setzen des höchstwertigen Bits ausreichen, um dem Steuergerät 12 mitzuteilen, ob die erste oder zweite Art der Authentifizierung durchgeführt werden soll. Der Analyseprozess 54 kann die Erzeugung eines ersten Zählers umfassen, der einen Zeitpunkt oder eine andere zeitliche Referenz markiert, die zur Vereitlung einer Anti-Replay-Verwendung von damit verbundenen Informationen verwendet werden kann, z.B. um eine zeitliche Beziehung zwischen Erzeugung und Verwendung der hier betrachteten Sicherheitsmaßnahmen zu gewährleisten.
Der Analyseprozess 54 kann die Generierung eines Challenge Message Authentication Code (MAC) 58 umfassen, der als Einmalschlüssel bezeichnet werden kann, indem die Challenge 48 mit einem dem Steuergerät 12 zugeordneten Unlock Key (ECUuk) signiert wird, nachdem das höchstwertige Bit auf 1 gesetzt oder auf 0 belassen wurde, d.h. der Challenge-MAC 58 umfasst die Unterfunktion, mit der das höchstwertige Bit je nach Art der Authentifizierung gesetzt oder belassen wird. Ein beispielhafter Challenge-MAC 58 ist nachstehend dargestellt. $MAC (ECUuk,challenge)$
Der Analyseprozess 54 kann zusätzlich die Generierung eines Daten-MAC 60 umfassen, indem zusätzliche Authentifizierungsdaten mit einem gemeinsamen geheimen Schlüssel signiert werden, der dem Backoffice 16 und dem Steuergerät 12 bekannt ist und der optional aus dem Entsperrschlüssel abgeleitet werden kann. Die hinzugefügten Authentifizierungsdaten können einer Verkettung der SoftpartNummer(n) und/oder der Modul-ID(s) mit dem/den entsprechenden Message Digest(s) entsprechen. Anders gesagt, der Message Digest kann mit dem/den Softpart(s) korrespondieren, der/die im Backoffice 16 mithilfe eines Algorithmus gehasht oder mit Fingerprint versehen wird/werden, so dass die hinzugefügten Authentifizierungsdaten dem Message Digest für jeden Softpart und die damit verketteten Zusatzinformationen entsprechen. Ein beispielhafter Daten-MAC 60 ist nachstehend dargestellt. $MAC (shared secret,additional authentication data)$
Ein Zähler-MAC 62 kann separat erzeugt werden, indem der erste Zähler mit dem gemeinsamen Geheimnis signiert wird. Ein beispielhafter Zähler-MAC 62 ist nachstehend dargestellt. $MAC (shared secret,first counter)$
Der Challenge-MAC 58, der Daten-MAC 60 und der Zähler-MAC 62 sowie die Challenge 48, die zusätzlichen Authentifizierungsdaten und der erste Zähler können vom Backoffice 16 in einer Nachricht 64 an das Programmiertool 14 übermittelt werden, wenn die zweite Art der Authentifizierung festgestellt ist. Ist die erste Art der Authentifizierung festgestellt, kann die Nachricht 64 stattdessen den Challenge-MAC 58 enthalten. Das Programmiertool 14 kann in Abhängigkeit von den in der Nachricht 64 enthaltenen Informationen einen Antwort-MAC 68 erzeugen, indem es eine erste Konstante mit dem Challenge-MAC 58 (d. h. dem Einmalschlüssel) signiert. Der Antwort-MAC 68 kann unabhängig davon generiert werden, ob die Authentifizierung von der ersten oder zweiten Art sein soll, d. h. die im Antwort-MAC 68 enthaltenen Informationen können für beide der hier betrachteten Authentifizierungsarten verwendet werden. Die erste Konstante kann verwendet werden, um einen zusätzlichen Schlüssel zu generieren, der als zusätzliche Sicherheitsmaßnahme die Verwendung unterschiedlicher Schlüssel für verschiedene Stufen ermöglicht. Ein beispielhafter Antwort-MAC 68 ist nachstehend dargestellt. $MAC (session key,first constant)$
Das Programmiertool 14 kann eine entsprechende Anforderung 72 an das Steuergerät 12 senden, z. B. mit einer 0x27-Sendeschlüsselanforderung. Das Steuergerät 12 verarbeitet die Sendeschlüsselanforderung 72, um festzustellen, ob die erste oder zweite Art der Authentifizierung erforderlich ist, so dass die damit verbundene Entscheidung die Challenge-Authentifizierung 46 effektiv abschließt. Die Sendeschlüsselanforderung 72 kann den Daten-MAC 60, den Zähler-MAC 62 und/oder den Antwort-MAC 68 sowie die Challenge 48, die zusätzlichen Authentifizierungsdaten, den ersten Zähler und die erste Konstante umfassen. Der Antwort-MAC 68 kann optional auf die x höchstwertigen Bytes beschränkt werden, um eine zusätzliche Sicherheitsoption zu bieten, d. h. x kann auf 12 oder eine andere Zahl gesetzt werden, um die höchstwertigen Bytes zu begrenzen, die gemäß einem Gestaltungsparameter verwendet werden, der einem Unbefugten wahrscheinlich unbekannt ist.
Das Steuergerät 12 kann als Reaktion auf den Empfang der Antwortnachrichten 72 einen Abgleich durchführen, indem es seine eigenen Werte für die in der Sendeschlüsselanforderung 72 empfangenen Informationen berechnet und dann seine Berechnungen mit den in der Sendeschlüsselanforderung 72 empfangenen Informationen/Werten vergleicht. Die Challenge-Authentifizierung 46 kann gegebenenfalls die Anzahl der Übereinstimmungen verwenden, um zu entscheiden, ob der Sicherheitszugriff zu gewähren ist, und wenn dieser gewährt wird, ob die erste oder zweite Art der Authentifizierung erforderlich ist. Ein nicht einschränkender Aspekt der vorliegenden Offenlegung sieht vor, dass das Steuergerät die y (z.B. 16) höchstwertigen Bytes der MAC-Challenge 58 und die 12 höchstwertigen Bytes des Antwort-MAC 68 vergleicht, um den Abgleich durchzuführen. Der Abgleich kann optional zunächst so durchgeführt werden, dass das Steuergerät 12 seine Werte berechnet, ohne das höchstwertige Bit der Challenge 48 zu setzen, d.h. der Challenge-MAC 58 wird berechnet, ohne dass das höchstwertige Bit der Unterfunktion gesetzt ist.
Wenn die von dem Steuergerät 12 berechneten Werte bei nicht gesetztem höchstwertigen Bit mit den in der Sendeschlüsselanforderung 72 empfangenen Werten übereinstimmen, stellt das Steuergerät 12 die Verifizierung des Sicherheitszugriffs aufgrund der Übereinstimmung fest und bestimmt, dass infolge der bei nicht gesetztem höchstwertige Bit der Unterfunktion vorliegenden Übereinstimmung die erste Art der Authentifizierung durchzuführen ist. Stimmen die von dem Steuergerät 12 berechneten Werte nicht mit den entsprechenden Werten in der Sendeschlüsselanforderung 72 überein, kann das Steuergerät einen weiteren Abgleich durchführen, wobei das höchstwertige Bit der Unterfunktion gesetzt ist. Wenn diese nachfolgende Operation eine Übereinstimmung zeigt, stellt das Steuergerät 12 die Verifizierung des Sicherheitszugriffs aufgrund der Übereinstimmung fest und bestimmt, dass infolge der bei gesetztem höchstwertige Bit der Unterfunktion vorliegenden Übereinstimmung die zweite Art der Authentifizierung durchzuführen ist. Erzielt das Steuergerät 12 nach Abschluss beider Abgleiche keine Übereinstimmung, stellt das Steuergerät fest, dass der Sicherheitszugriff nicht verifiziert ist und verweigert die Sicherheitszugriffsanforderung zur Durchführung von Softpart-Aktualisierungen.
Das Steuergerät 12 kann ein Flag für den Sicherheitszugriffs und ein Flag für erforderliche zusätzliches Authentifizierung entsprechend den Ergebnissen der Abgleiche setzen und so beispielsweise das Flag für den Sicherheitszugriff bei Verifizierung einer Übereinstimmung auf wahr setzen, das Flag für zusätzliche Authentifizierung auf falsch setzen, wenn die erste Art der Authentifizierung erforderlich ist, und das Flag für zusätzliche Authentifizierung auf wahr setzen, wenn die zweite Art der Authentifizierung erforderlich ist. Das Steuergerät 12 kann eine entsprechende Antwort 76 an das Programmiertool 14 senden, z. B. mit einer 0x27-Sendeschlüsselantwort, um dem Programmiertool 14 mitzuteilen, ob der Sicherheitszugriff gewährt oder verweigert wurde, d. h. ob die Softpart-Aktualisierung erlaubt ist. Entweder durch zusätzliche Kommunikation vom Backoffice 16 oder durch Informationen, die in der Utility-Datei 28 enthalten sind, kann das Programmiertool 14 wissen, ob die erste oder zweite Art der Authentifizierung erforderlich ist. Weiß das Programmiertool 14 davon jedoch nichts, kann die Sendeschlüsselantwort 76 optional Informationen darüber enthalten, ob die erste oder zweite Art der Authentifizierung erforderlich ist.
Das Programmiertool 14 kann daraufhin eine Zähleranforderung 78 an das Steuergerät 12 mit dem ersten Zähler senden. Das Steuergerät 12 kann dann den ersten Zähler speichern, um zu markieren, wann die mit der Authentifizierungs-Challenge 46 verbundenen Informationen erzeugt wurden. Daraufhin kann eine Zählerantwortnachricht 80 gesendet werden, um zu bestätigen, dass das Steuergerät 12 den ersten Zähler akzeptiert. Das Programmiertool 14 kann dann eine Zugangsanforderung für Programming-Session 82 senden, um dem Steuergerät 12 seine Absicht anzuzeigen, mit der Softpart-Aktualisierung zu beginnen. Das Steuergerät 12 kann daraufhin eine Antwort auf die Zugangsanforderung für Programming-Session 84 generieren, um die Bereitschaft zum Beginn der Softpart-Aktualisierungen anzuzeigen. Ist die zweite Art der Authentifizierung erforderlich, um die Softpart-Aktualisierung abzuschließen, sendet das Programmiertool 14 eine Anforderung zusätzlicher Authentifizierungsdaten 86 an das Steuergerät 12. Die zusätzliche Authentifizierungsanforderung 86 kann den Daten-MAC 60, die zusätzlichen Authentifizierungsdaten und einen zweiten Zähler enthalten, wobei der zweite Zähler der zeitlichen Identifizierung des Zeitpunkts der Anforderung 86 dient.
Das Steuergerät 12 kann als Reaktion auf die Anforderung zusätzlicher Authentifizierungsdaten 86 einen Datenauthentifizierungsprozess 88 einleiten. Der Datenauthentifizierungsprozess 88 kann damit einhergehen, dass das Steuergerät 12 prüft, ob der zweite Zähler größer als der erste Zähler ist, und wenn ja, seinen eigenen Daten-MAC für die zusätzlichen Autorisierungsdaten berechnet und mit dem Daten-MAC 60 vergleicht. Das Steuergerät 12 kann einen zusätzlichen Authentifizierungs-MAC erzeugen, indem es die zusätzlichen Authentifizierungsdaten mit einem zusätzlichen Authentifizierungsschlüssel signiert. Der zusätzliche Authentifizierungsschlüssel kann von dem Steuergerät 12 generiert werden, um das gemeinsame Geheimnis zu imitieren, so dass der von dem Steuergerät 12 ermittelte zusätzliche Authentifizierungs-MAC mit dem vom Backoffice 16 empfangenen Daten-MAC 60 verglichen werden kann. Der zusätzliche Authentifizierungsschlüssel kann z. B. durch Signieren einer zusätzlichen Authentifizierungsschlüsselkonstante mit dem darin gespeicherten Entsperrschlüssel oder optional einem davon abgeleiteten Schlüssel erzeugt werden.
Im Falle einer Übereinstimmung stellt das Steuergerät 12 fest, dass die vom Programmiertool 14 bereitgestellten zusätzlichen Authentifizierungsdaten gültig sind. Das Steuergerät 12 kann daraufhin einige oder alle Message Digests der Softparts, die den Modul-IDs entsprechen, speichern, um das Aktualisieren des Speichers des Steuergeräts 12 zu ermöglichen. Das Steuergerät 12 kann eine zusätzliche Authentifizierungsdaten-Antwort 92 an das Programmiertool 14 senden, wenn das Steuergerät 12 feststellt, dass die im Backoffice 16 erzeugten zusätzlichen Authentifizierungsdaten ordnungsgemäß empfangen wurden, d. h., dass sie als seit der Übertragung vom Backoffice 16 nicht manipuliert verifiziert wurden.
Eine Datenübertragung 94 kann damit beginnen, dass das Programmiertool 14 im Steuergerät 12 Antwort- und Anforderungsnachrichten austauscht, wodurch der Softpart dem Steuergerät 12 bereitgestellt wird und das Steuergerät 12 daraufhin Partitionen löscht und anderweitig dessen Download ermöglicht. Vor der Installation des Softparts und/oder Gestattung von dessen Ausführung kann ein Modul-Authentifizierungsprozess 100 mit dem Steuergerät 12 korrespondieren und die Authentizität des bereitgestellten Softparts verifizieren, indem es beispielsweise den Message Digest des bereitgestellten Softparts generiert und mit den gespeicherten Softpart-Message-Digests vergleicht, die vom Programmiertool 14 bereitgestellt werden und mit den im Steuergerät 12 enthaltenen Modul-IDs korrespondieren, um zusätzlich die Gültigkeit der Signatur des Softparts zu überprüfen. Die Modul-IDs können verwendet werden, um bestimmte zu aktualisierende Partitionen oder andere Aspekte des Steuergeräts 12 zu identifizieren, und somit kann die Überprüfung dieser IDs ein nützlicher letzter Schritt sein, bevor das Steuergerät 12 die Installation der Software gestattet. Das Steuergerät 12 kann nach der Verifizierung der Aktualisierung eine Übertragungsdatenantwort 102 senden.
Die detaillierte Beschreibung und die Zeichnungen oder Figuren unterstützen und beschreiben die vorliegende Lehre, wobei der Umfang der vorliegenden Lehre aber ausschließlich durch die Ansprüche definiert ist. Während einige der besten Modi und andere Ausgestaltungen für die Durchführung der vorliegenden Lehre im Detail beschrieben wurden, gibt es verschiedene alternative Konstruktionen und Ausführungsformen, um die vorliegende Lehre, die in den im Anhang aufgeführten Ansprüchen definiert ist, durchzuführen. Darüber hinaus schließt diese Offenbarung ausdrücklich Kombinationen und Unterkombinationen der vor- und nachstehend dargelegten Elemente und Merkmale ein.

Claims

Verfahren zur Authentifizierung einer Softpart-Aktualisierung für eine elektronische Steuereinheit (ECU), umfassend: Festlegen von Sendeschlüsselinformationen, die in einer Sendeschlüsselanforderung enthalten sind, die von einem Programmiertool an das Steuergerät übertragen wird; und Identifizieren aus der Sendeschlüsselinformationen, ob die Softpart-Aktualisierung gemäß einer ersten Art von Authentifizierung oder einer zweiten Art von Authentifizierung zu authentifizieren ist, wobei das Steuergerät dazu ausgelegt ist, sowohl die erste als auch die zweite Art durchzuführen, wobei die erste Art es dem Steuergerät ermöglicht, eine Aktualisierung bei Abschluss einer Authentifizierung des Entsperrschlüssels durchzuführen und die zweite Art es dem Steuergerät ermöglicht, eine Aktualisierung bei Authentifizierung eines für den Softpart erstellten Message-Digest zusätzlich zum Abschluss einer Authentifizierung des Entsperrschlüssels durchzuführen.
Verfahren nach Anspruch 1, ferner die Aufforderung an das Steuergerät umfassend, eine Challenge-Authentifizierung durchzuführen, um zu ermitteln, ob die Aktualisierung nach der ersten oder der zweiten Art zu authentifizieren ist, z. B. um die Authentifizierung bei erfolgloser Challenge-Authentifizierung nach der ersten Art und nach erfolgreicher Challenge-Authentifizierung nach der zweiten Art durchzuführen.
Verfahren nach Anspruch 2, ferner das Feststellen umfassend, dass die Challenge-Authentifizierung erfolgreich ist, wenn das Steuergerät sowohl einen Challenge-Message-Authentifizierungscode (MAC) als auch einen Antwort erzeugt und mit den entsprechenden Challenge- und Antwort-MACs abgleicht, die in den Sendeschlüsselinformationen enthalten sind.
Verfahren nach Anspruch 3, ferner die Anforderung an das Steuergerät umfassend, den Challenge-MAC durch Signieren einer Challenge mit einem Entsperrschlüssel zu erzeugen.
Verfahren nach Anspruch 4, ferner die Anforderung an das Steuergerät umfassend, die Challenge durch Setzen eines höchstwertigen Bits einer Unterfunktion vor der Verkettung der Unterfunktion mit einem Seed zu erzeugen, wobei das Steuergerät den Seed durch Verkettung einer Steuergerätekennung (ID) mit einer Zufallszahl erzeugt.
Verfahren nach Anspruch 5, ferner umfasst ferner die Anforderung an das Steuergerät, den Antwort-MAC durch Signieren einer ersten Konstante mit einem Session-Schlüssel zu erzeugen.
Verfahren zur Authentifizierung einer Softpart-Aktualisierung für ein elektronisches Steuergerät (ECU) eines Kraftfahrzeugs, wobei das Verfahren Folgendes umfasst: entsprechend der von einem Programmiertool an das Steuergerät übertragenen Informationen die Authentifizierung der Softpart-Aktualisierung in Reaktion auf die Verifizierung eines Entsperrschlüssels und einer Message Digest des Softparts durch das Steuergerät, wobei der Entsperrschlüssel und das Message Digest in den Informationen enthalten sind und das Message Digest dem Programmiertool von einem Backoffice zur Authentifizierung der Softpart-Aktualisierung bereitgestellt wird.
Verfahren nach Anspruch 7, ferner umfassend das Feststellen des zu verifizierenden Message Digest durch das Steuergerät, wenn ein damit verbundenen und in den Informationen enthaltener Message-Authentifizierungscode (MAC) mit einem entsprechenden, von dem Steuergerät erzeugten MAC übereinstimmt.
System zur Authentifizierung eines Softparts für ein elektronisches Steuergerät (ECU) eines Kraftfahrzeugs, wobei das System Folgendes umfasst: ein Backoffice, das zur Erzeugung eines Message Digest und einer Signatur für den Softpart ausgelegt ist, wobei das Backoffice den Message Digest und die Signatur in Reaktion auf die Überprüfung der Authentizität einer Softpart-Aktualisierung erzeugt; und ein Programmiertool, das dazu ausgelegt ist, den Message Digest und die Signatur zusammen mit den dem Steuergerät zur Verfügung gestellten Informationen zu senden, wobei das Steuergerät auf Grundlage der Informationen über die Verifizierung der Aktualisierung entscheidet.
System nach Anspruch 9, wobei das Programmiertool einen Entsperrschlüssel und einen Message-Authentifizierungscode (MAC) für den in den Informationen enthaltenen Message Digest umfasst, auf deren Grundlage das Steuergerät die Verifizierung der Aktualisierung feststellt, wenn der MAC, die Signatur und der Entsperrschlüssel mit einem vom Steuergerät festgelegten MAC, Signatur und Entsperrschlüssel übereinstimmen.