DE102018120915A1

DE102018120915A1 - Fahrzeuginterne Gruppenschlüsselverteilung

Info

Publication number: DE102018120915A1
Application number: DE102018120915.0A
Authority: DE
Inventors: Xin Ye; Jason Michael Miller; Piyush I. PATEL
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2017-08-30
Filing date: 2018-08-27
Publication date: 2019-02-28
Also published as: US20190068361A1; CN109428716A

Abstract

Ein Gateway beinhaltet ein Hardware-Sicherheitsmodul (hardware security module - HSM), das einen Hardware-Zufallszahlengenerator umsetzt, und einen nichtflüchtigen Speicher, der eine Schlüsselinjektionsstatustabelle (key injection status table - KIST) führt. Das Gateway ist dazu programmiert, unter Verwendung des Zufallszahlengenerators generierte Schlüssel als Reaktion auf einen Auslöser zum Beginnen der Schlüsselverteilung, der von einem Werkzeug am Ende der Linie (end-of-line tool - EOL-Werkzeug) empfangen wird, an eine Vielzahl von elektronischen Steuereinheiten (electronic control units - ECUs) zu verteilen und die KIST als Reaktion auf den Abschluss der Schlüsselverteilung an das EOL-Werkzeug zu senden. Ein unter Verwendung eines Hardware-Zufallszahlengenerators generierter Schlüssel wird als Reaktion darauf, dass eine eindeutige Kennung (unique identifier - UID) der ECU über einen Fahrzeugbus empfangen wird, in einer verschlüsselten Nachricht an eine elektronische Steuereinheit (ECU) eines Fahrzeugs gesendet. Als Reaktion auf eine Erfolgsangabe von der ECU in einer zweiten verschlüsselten Nachricht wird eine Schlüsselinjektionsstatustabelle (KIST) aktualisiert, um anzugeben, dass der Schlüssel auf die ECU angewendet wurde.

Description

TECHNISCHES GEBIET
Aspekte der Offenbarung betreffen die sichere Verteilung von kryptografischen Schlüsseln an fahrzeuginterne bordseitige elektronische Steuereinheiten (electronics control units - ECUs) während der Fahrzeugmontage.
ALLGEMEINER STAND DER TECHNIK
Algorithmen mit symmetrischen Schlüsseln sind Algorithmen zur Kryptografie, die sowohl zur Verschlüsselung von Klartext als auch Entschlüsselung von Geheimtext die gleichen kryptografischen Schlüssel verwenden. Die Schlüssel können identisch sein oder es kann eine einfache Umwandlung zwischen den zwei Schlüsseln erfolgen. Ein Fahrzeugbus ist ein spezialisiertes internes Kommunikationsnetz, das Komponenten innerhalb eines Fahrzeugs miteinander verbindet. Besondere Anforderungen an die Fahrzeugsteuerung, wie etwa Gewissheit von Nachrichtenzustellung, von nicht in Konflikt stehenden Nachrichten, von Mindestzeit zur Zustellung, von geringen Kosten und von EMF-Rauschwiderstandsfähigkeit sowie redundantes Routing und andere Merkmale geben die Verwendung von fahrzeugspezifischen Kommunikationsprotokollen vor. Da Fahrzeuge immer stärker von der internen Kommunikation zwischen Komponenten abhängig sind, wird der sichere Nachrichtenaustausch zwischen den Komponenten zu einer höheren Priorität bei der Gestaltung und Umsetzung von fahrzeuginternen Kommunikationssystemen.
KURZDARSTELLUNG
In einer oder mehreren veranschaulichenden Ausführungsformen beinhaltet ein System ein Gateway, das ein Hardware-Sicherheitsmodul (hardware security module - HSM), das einen Hardware-Zufallszahlengenerator umsetzt, und einen nichtflüchtigen Speicher, der eine Schlüsselinjektionsstatustabelle (key injection status table - KIST) führt, beinhaltet und dazu programmiert ist, unter Verwendung des Zufallszahlengenerators generierte Schlüssel als Reaktion auf einen Auslöser zum Beginnen der Schlüsselverteilung, der von einem Werkzeug am Ende der Linie (end-of-line tool - EOL-Werkzeug) empfangen wird, an eine Vielzahl von elektronischen Steuereinheiten (electronic control units - ECUs) zu verteilen und die KIST als Reaktion auf den Abschluss der Schlüsselverteilung an das EOL-Werkzeug zu senden.
In einer oder mehreren veranschaulichenden Ausführungsformen beinhaltet ein Verfahren Senden eines unter Verwendung eines Hardware-Zufallszahlengenerators generierten Schlüssels in einer verschlüsselten Nachricht an eine elektronische Steuereinheit (ECU) eines Fahrzeugs als Reaktion darauf, dass eine eindeutige Kennung (unique identifier - UID) der ECU über einen Fahrzeugbus empfangen wird; und als Reaktion auf eine Erfolgsangabe von der ECU in einer zweiten verschlüsselten Nachricht Aktualisieren einer Schlüsselinjektionsstatustabelle (KIST), um anzugeben, dass der Schlüssel auf die ECU angewendet wurde.
In einer oder mehreren veranschaulichenden Ausführungsformen beinhaltet ein System einen Prozessor, der dazu programmiert ist, als Reaktion auf eine Erfolgsangabe von einer ECU in einer verschlüsselten Antwortnachricht, die als Reaktion darauf empfangen wird, dass ein unter Verwendung eines Hardware-Zufallszahlengenerators generierter Schlüssel in einer verschlüsselten Anforderungsnachricht an die ECU gesendet wird, eine Schlüsselinjektionsstatustabelle (KIST) zu aktualisieren, um anzugeben, dass der Schlüssel auf die ECU angewendet wurde.
Figurenliste

1 veranschaulicht eine beispielhafte Systemtopologie zum Bereitstellen von Kommunikation zwischen einer Vielzahl von ECUs eines Fahrzeugs;
2 veranschaulicht eine beispielhafte Umsetzung eines Stapels für ein fahrzeugseitiges Telematikprotokoll (on-vehicle telematics protocol - OVTP);
3 veranschaulicht einen beispielhaften Prozess zum Durchführen der sicheren Schlüsselverteilung; und
4 veranschaulicht ein beispielhaftes Datenflussdiagramm zum Durchführen der sicheren Schlüsselverteilung.

DETAILLIERTE BESCHREIBUNG
Ausführliche Ausführungsformen der vorliegenden Erfindung sind hier nach Bedarf offenbart; dabei versteht es sich jedoch, dass die offenbarten Ausführungsformen für die Erfindung, die in verschiedenen und alternativen Formen ausgeführt sein kann, lediglich beispielhaft sind. Die Figuren sind nicht unbedingt maßstabsgetreu; einige Merkmale können vergrößert oder verkleinert dargestellt sein, um Details bestimmter Komponenten zu zeigen. Daher sind die hier offenbarten konkreten strukturellen und funktionellen Details nicht als einschränkend auszulegen, sondern lediglich als repräsentative Grundlage, um den Fachmann die vielseitige Verwendung der vorliegenden Erfindung zu lehren.
Das Verteilen von symmetrischen Schlüsseln an unterschiedliche ECUs ist eine Voraussetzung dafür, die bordseitige Kommunikation unter ECUs innerhalb eines Fahrzeugs abzusichern. Diese sichere Kommunikation kann als einige Beispiele Nachrichtenauthentifizierung und -verschlüsselung bei verschiedenen Arten von fahrzeuginternen Netzwerken (wie etwa Controller Area Network (CAN), CAN-FD, Ethernet etc.) beinhalten. Die Schlüssel auf sichere Art und Weise zu verteilen ist jedoch üblicherweise eine komplizierte Aufgabe. Eine grundlegende Anforderung besteht darin, dass die Schlüssel für unterschiedliche Fahrzeuge unabhängig voneinander generiert werden sollten. Diese Anforderung spiegelt das Grundprinzip wider, dass in dem Fall, dass ein Schlüssel an einem Fahrzeug kompromittiert ist, dieser kompromittierte Schlüssel nicht die Sicherheit von anderen Fahrzeugen beeinflusst. Eine zweite allgemeine Sicherheitsanforderung besteht darin, dass die generierten Schlüssel ein gewisses Maß an Entropie aufrechterhalten sollen. Zum Beispiel sollten Schlüssel laut AES-128 so generiert werden, dass sie eine Entropie von 128 bit aufweisen. Das Sicherstellen eines ausreichenden Maßes an Entropie erfordert die Generierung von echten Zufallszahlen auf Basis von dedizierter Hardware.
Schlüsselverteilung kann am Fahrzeugmontageband durchgeführt werden, um sichere Kommunikation zwischen ECUs in gebauten Fahrzeugen bereitzustellen. Dazu ist es erforderlich, mehreren Einschränkungen zu entsprechen, wie etwa Netzwerkkonnektivität, Taktzeit und Fahrzeugwerksprozesse. Wie hier ausführlich erläutert, wird ein Schlüsselverteilungsprotokoll vorgeschlagen, das diese Sicherheitsziele erreicht, während die Auswirkungen auf bestehende Fahrzeugmontageprozesse minimiert werden.
1 veranschaulicht eine beispielhafte Systemtopologie 100 zum Bereitstellen von Kommunikation zwischen einer Vielzahl von ECUs 104 eines Fahrzeugs 102. Jede ECU 104 ist mit einem einer Vielzahl von Teilnetzen 110 verbunden. Eine Telematiksteuereinheit (telematics control unit - TCU) 106-A und eine Fahrzeugunterhaltungssteuerung 106-B sind (gemeinsam oder separat) dazu konfiguriert, Kommunikation zwischen verschiedenen Komponenten des Fahrzeugs 102 und denen von anderen Fahrzeugen 102 und/oder mobilen Vorrichtungen über externe und fahrzeuginterne Netzwerke (nicht gezeigt) zu erleichtern. Die TCU 106-A und die Unterhaltungssteuerung 106-B (nachstehend Backbone-Steuerungen 106) können mit einem als Backbone 112 dienenden Abschnitt der Systemtopologie 100 verbunden sein und miteinander und/oder mit den ECUs 104 kommunizieren. Wenngleich in 1 eine beispielhafte Systemtopologie 100 gezeigt ist, sollen die veranschaulichten beispielhaften Komponenten nicht der Einschränkung dienen. Tatsächlich kann die Systemtopologie 100 mehr oder weniger Komponenten aufweisen und es können zusätzliche oder alternative Komponenten und/oder Umsetzungen verwendet werden. Beispielsweise können die ECUs 104 und die Backbone-Steuerungen 106 jeweils mit einer oder mehreren gleichen oder unterschiedlichen Arten von Knoten als die Teilnetze 110 und das Backbone 112 verbunden sein.
Bei dem Fahrzeug 102 kann es sich zum Beispiel um verschiedene Arten von Automobilen, Softroadern (crossover utility vehicle - CUV), Geländelimousinen (sport utility vehicle - SUV), Trucks, Wohnmobilen (recreational vehicle - RV), Booten, Flugzeugen oder anderen mobilen Maschinen zum Befördern von Personen oder Gütern handeln. In vielen Fällen kann das Fahrzeug 102 durch einen Verbrennungsmotor angetrieben werden. Als eine andere Möglichkeit kann das Fahrzeug 102 ein Hybridelektrofahrzeug (hybrid electric vehicle - HEV) sein, das sowohl durch einen Verbrennungsmotor als auch einen oder mehrere Elektromotoren angetrieben wird, wie etwa ein Serienhybrid-Elektrofahrzeug (series hybrid electric vehicle - SHEV), ein Parallelhybrid-Elektrofahrzeug (parallel hybrid electrical vehicle - PHEV) oder ein Parallel-/Serienhybrid-Elektrofahrzeug (parallel/series hybrid electric vehicle - PSHEV). Da die Art und Konfiguration des Fahrzeugs 102 variieren können, können entsprechend auch die Betriebseigenschaften des Fahrzeugs variieren. Als einige andere Möglichkeiten kann das Fahrzeug 102 andere Eigenschaften in Bezug auf Fahrgastkapazität, Zugfähigkeit und -kapazität sowie Lagervolumen aufweisen.
Die ECUs 104 können verschiedene Hardware- und Softwarekomponenten beinhalten und können dazu konfiguriert sein, verschiedene Fahrzeugfunktionen, die von der Batterie und/oder dem Antriebsstrang des Fahrzeugs 102 mit Leistung versorgt werden, zu überwachen und zu verwalten. Die ECUs 104 können dementsprechend einen oder mehrere Prozessoren (z. B. Mikroprozessoren) (nicht gezeigt) beinhalten, die dazu konfiguriert sind, Firmware- oder Softwareprogramme auszuführen, die in einer oder mehreren Speichervorrichtungen (nicht gezeigt) der ECUs 104 gespeichert sind. Wenngleich die ECUs 104 als separate Komponenten veranschaulicht sind, können die Fahrzeug-ECUs 104 über gemeinsame physische Hardware, Firmware und/oder Software verfügen, sodass die Funktionalität von mehreren ECUs 104 in eine einzelne ECU 104 integriert werden kann und sodass die Funktionalität verschiedener derartiger ECUs 104 auf eine Vielzahl von ECUs 104 verteilt werden kann.
Zu den ECUs 104 können eine Antriebsstrangsteuerung 104-A, die dazu konfiguriert ist, Betriebskomponenten in Zusammenhang mit einer oder mehreren Leistungsquellen des Fahrzeugs wie etwa einen Motor, eine Batterie und so weiter zu verwalten, eine Getriebesteuerung 104-B, die dazu konfiguriert ist, die Leistungsübertragung zwischen dem Antriebsstrang und den Rädern des Fahrzeugs zu verwalten, eine Karosseriesteuerung 104-C, die dazu konfiguriert ist, verschiedene Leistungssteuerungsfunktionen wie etwa Außenbeleuchtung, Innenbeleuchtung, schlüssellosen Zugang, Fernstart und Verifikation des Status von Zugangspunkten zu verwalten, ein Scheinwerfersteuermodul (headlamp control module - HCM) 104-D, das dazu konfiguriert ist, An-/Aus-Einstellungen der Leuchten, mobile Vorrichtungen oder andere lokale Vorrichtungen des Fahrzeugs 102 zu steuern, fortschrittliche Fahrerassistenzsysteme (advanced driver assistance systems - ADAS) 104-E wie etwa adaptive Geschwindigkeitsregelung oder automatisiertes Bremsen, eine Steuerung zur Klimasteuerungsverwaltung 104-F, die dazu konfiguriert ist, Heiz- und Kühlsystemkomponenten (z. B. Kompressorkupplung, Gebläselüfter, Temperatursensoren etc.) zu überwachen und verwalten, und eine Steuerung für das globale Positionsbestimmungssystem (global positioning system - GPS) 104-G, die dazu konfiguriert ist, Fahrzeugstandortinformationen bereitzustellen, gehören. Es sollte angemerkt werden, dass es sich hierbei lediglich um Beispiele handelt und Fahrzeuge 102 mehr oder weniger ECUs 104 beinhalten können oder andere verwendet werden können.
Die Backbone-Steuerungen 106, z. B. die TCU 106-A und die Unterhaltungssteuerung 106-B, können jeweils einen oder mehrere Prozessoren (nicht gezeigt) (z. B. Mikroprozessoren) beinhalten, die dazu konfiguriert sind, Firmware- oder Softwareprogramme auszuführen, die auf einer oder mehreren jeweiligen Speichervorrichtungen der TCU 106-A und der Unterhaltungssteuerung 106-B gespeichert sind.
Die TCU 106-A kann ein Modem oder andere Netzwerkhardware beinhalten, um die Kommunikation zwischen dem Fahrzeug 102 und einem oder mehreren Netzwerken außerhalb des Fahrzeugs 102 zu erleichtern. Diese externen Netzwerke können als einige nicht einschränkende Beispiele das Internet, ein Kabelfernsehverteilungsnetzwerk, ein Satellitenverbindungsnetzwerk, ein lokales Netzwerk, ein Weitverkehrsnetzwerk und ein Telefonnetzwerk beinhalten.
Die Unterhaltungssteuerung 106-B kann dazu konfiguriert sein, eine Sprachbefehlschnittstelle mit Fahrzeuginsassen sowie lokale Verbindungsschnittstellen mit tragbaren Vorrichtungen der Fahrzeuginsassen zu unterstützen. In einem Beispiel kann die Unterhaltungssteuerung 106-B dazu konfiguriert sein, mit den tragbaren Vorrichtungen über eines oder mehrere von BLUETOOTH-, WLAN- und drahtgebundenen USB-Netzwerkverbindungen zu kommunizieren. Diese Verbindungen können dazu verwendet werden, die Datenübertragung mit tragbaren Vorrichtungen zu erleichtern, die dazu konfiguriert sind, mit einem oder mehreren der externen Netzwerke zu kommunizieren. Als eine Möglichkeit kann die Unterhaltungssteuerung 106-B eine Steuerung des Systems FORD SYNC sein, das durch die FORD MOTOR COMPANY in Dearborn, MI bereitgestellt wird.
Das Fahrzeug 102 kann das Gateway 108 beinhalten. In einem Beispiel kann das Gateway 108 die Funktionalität eines intelligenten Datenverbindungssteckers (smart data link connector - SDLC) umsetzen. Das Gateway 108 kann dazu konfiguriert sein, den Datenaustausch zwischen Fahrzeug-ECUs 104 zu erleichtern. Das Gateway 108 kann ferner dazu konfiguriert sein, den Datenaustausch zwischen den Fahrzeug-ECUs 104 und der einen oder den mehreren Backbone-Steuerungen 106, die an dem Backbone 112 angeordnet sind, zu erleichtern. In einem Beispiel können die Fahrzeug-ECUs 104 und die Backbone-Steuerungen 106 unter Verwendung eines CAN-Kommunikationsprotokolls, wie etwa unter anderem eines Hochgeschwindigkeits-(high-speed - HS-)CAN, eines Mittelgeschwindigkeits-(mid-speed - MS-)CAN oder eines Niedergeschwindigkeits-(low-speed - LS-)CAN, mit dem Gateway 108 kommunizieren. Unterschiedliche Teilnetze 110 können unterschiedliche CAN-Protokollgeschwindigkeiten verwenden. In einem Beispiel können eines oder mehrere der Teilnetze HS-CAN umsetzen, während ein anderes oder mehrere andere Teilnetze 110 MS-CAN umsetzen können. In noch anderen Beispielen kann das Gateway 108 dazu konfiguriert sein, Kommunikation unter Verwendung von einem oder mehreren von einem Ethernet-Netzwerk, einem Media-Oriented-System-Transport-(MOST-)Netzwerk, einem FlexRay-Netzwerk oder einem Local Interconnect Network (LIN) zu erleichtern.
Eines oder mehrere der Teilnetze 110 können ein Hauptteilnetz definieren, das als Backbone 112 bezeichnet werden kann. Das Backbone 112 kann einen Abschnitt der Systemtopologie 100 beinhalten, der dazu konfiguriert ist, als verbindender Kommunikationspunkt für die anderen Teilnetze 110 des Fahrzeugs 102 zu dienen. Dementsprechend kann das Backbone 112 dazu konfiguriert sein, Datenverkehr in einem größeren Volumen zu verwalten und zu routen, als über die anderen Teilnetze 110 bereitgestellt wird. Unter Verwendung der Nachrichtenverarbeitungsmerkmale des Gateways 108 kann das Gateway 108 dazu konfiguriert sein, Nachrichtenrahmen zwischen den Backbone-Steuerungen 106, die an dem Backbone 112 angeordnet sind, und der einen oder den mehreren Fahrzeug-ECUs 104, die an den anderen Teilnetzen 110 angeordnet sind, zu übertragen.
Das Gateway 108 kann dazu konfiguriert sein, festzustellen, an welchem Teilnetz 110 jede der ECUs 104, 106 angeordnet ist. Dies kann gemäß einer entsprechenden physischen Netzwerkadresse der ECUs 104, 106 erreicht werden. In einem Beispiel kann das Gateway 108 als Reaktion darauf, dass es eine Anforderung zum Routen einer Nachricht an eine gegebene ECU 104, 106 empfängt, einen Speicher dazu auffordern, eine Netzwerkadresse festzustellen, die der ECU 104, 106 entspricht. Zum Beispiel kann das Gateway 108 einen Speicher beinhalten, der dazu konfiguriert ist, die Netzwerkadressen sowie ein Routingschema zu speichern, das definiert, welche Nachrichten zu welchen Teilnetzen 110 und/oder dem Backbone 112 geroutet werden. Dieses Routing kann durch das Gateway 108 auf Grundlage von in der Nachricht enthaltenen vordefinierten Parametern wie etwa einer Art von Nachricht und/oder Kennungen der ECUs 104, 106, die den Ursprung und/oder das Ziel der Nachricht benennen, bestimmt werden.
Unter Verwendung der in 1 veranschaulichten Systemtopologie 100 kann in einem Fahrzeugmontagewerk integrierte Schlüsselverteilung erfolgen. Dies kann so bezeichnet werden, dass sie auf der Stufe des Fahrzeugbetriebs (vehicle operation - VO) durchgeführt wird. Die integrierte Schlüsselverteilung kann ein Vertrauensverhältnis zwischen unterschiedlichen Gruppen von ECUs 104 an dem gleichen Fahrzeug 102 aufbauen, was authentifizierte Kommunikation zwischen den ECUs 104 ermöglichen kann. Um die Auswirkungen auf den VO-Prozess bei Vorprozessen und bei dynamischen und statischen Stationen am Ende der Linie (EOL) zu minimieren, wird der Prozess bei Vorprozessen mit einer einfachen Diagnoseanforderung eingeleitet und arbeitet im Hintergrund, während sich der Schlüssel in der AN-Position befindet.
Ein EOL-Werkzeug 120 kann mit dem Fahrzeug 102 verbunden werden, in einem Beispiel über einen On-Board-Diagnose-(OBD-)Anschluss oder eine andere Verbindung mit dem Nachrichtenaustausch des Fahrzeugs 102. Der Prozess kann dementsprechend bis zum Ende der statischen EOL-Station abgeschlossen sein, wo das EOL-Werkzeug 120 dazu verwendet werden kann, zu bestätigen, dass die Schlüsselverteilung erfolgreich abgeschlossen worden ist, und eine Schlüsselinjektionsstatustabelle (KIST) 118 anzufordern/aufzuzeichnen, die Paarungen aus Fahrzeug-Identifizierungsnummer (FIN) und eindeutiger Kennung (UID) zur nachgelagerten Verwendung beinhaltet. Der Prozess erfordert dementsprechend wenig Interaktion mit dem EOL-Werkzeug 120 und die entscheidende Einschränkung der Einhaltung der Taktzeit wird dadurch minimiert, dass ermöglicht wird, dass das Gateway 108 den Prozess mit den ECUs 104 im Hintergrund verwaltet.
Das Gateway 108 kann die Vorgänge eines Schlüsselgenerators und -verteilers durchführen. Zur Unterstützung dieser Vorgänge beinhaltet das Gateway 108 ein Hardware-Sicherheitsmodul (HSM) 114, das einen Generator für echte Zufallszahlen zur Verwendung bei der Generierung von Sicherheitsschlüsseln beinhaltet. Ein HSM 114 bezieht sich auf eine physische Rechenvorrichtung, die digitale Schlüssel zur starken Authentifizierung sichert und verwaltet und Kryptoverarbeitung bereitstellt. Ein Generator für echte Zufallszahlen ist eine Hardwarekomponente an einer Vorrichtung, die Zufallszahlen anhand eines physischen Prozesses generiert und nicht anhand der Durchführung von Schritten eines Computeralgorithmus. In einem Beispiel kann das HSM 114 Wärmerauschen oder den photoelektrischen Effekt als zugrundeliegendes physikalisches Phänomen zum Abtasten für die Generierung von numerischen Werten verwenden.
Jede der ECUs 104 kann eine Kombination aus HSM / sicherer Hardware-Erweiterung (Secure Hardware Extension - SHE) 116 beinhalten. Ähnlich wie vorstehend unter Bezugnahme auf das Gateway 108 erörtert, kann es sich bei der HSM/SHE 116 um eine physische Rechenvorrichtung handeln, die digitale Schlüssel zur starken Authentifizierung sichert und verwaltet und Kryptoverarbeitung bereitstellt. Die ECUs 104 können die generierten Schlüssel von dem Gateway 108 empfangen und die erzeugten Schlüssel in der HSM/SHE 116 speichern. Dementsprechend kann die HSM/SHE 116 dazu konfiguriert sein, das Lesen und unautorisierte Schreiben in den Wert der Sicherheitsschlüssel zu verhindern.
Wie nachstehend ausführlicher erläutert, kann der Schlüsselverteilungsprozess laut einem zweischichtigen Protokoll durchgeführt werden. Eine äußere Schicht kann ein fahrzeugseitiges Telematikprotokoll (OVTP) sein, das definiert, wie das Gateway 108 mit anderen ECUs 104 kommuniziert. Eine innere Schicht kann ein SHE-Funktionsprotokoll sein, das reguliert, wie der Mikrocontroller des Hosts für die ECU 104 mit der entsprechenden peripheren SHE/HSM 116 der ECU 104 kommuniziert, und das die Ermöglichung der sicheren Schlüsselaktualisierung für die ECU 104 sequenziert.
Das Gateway 108 kann der Host der KIST 118 sein. Die KIST 118 kann Statusinformationen führen, die angeben, welche Schlüssel an welchen gewünschten Schlüsselslots in welche ECU 104 injiziert worden sind. Indem die KIST 118 verwendet wird, können EOL-Systeme wie etwa das EOL-Werkzeug 120 überprüfen, ob in alle gewünschten Schlüsselslots an allen gewünschten ECUs 104 an einem Fahrzeug 102 Schlüssel injiziert werden.
2 zeigt eine beispielhafte Umsetzung 200 eines OVTP-Protokollstapels 202. Unter Verwendung der beispielhaften Umsetzung 200 können die ECUs 104, 106 dazu in der Lage sein, CAN-Nachrichten einschließlich 29-bit-Nachrichtenkennungen 220 zu senden und/oder zu empfangen. Der Stapel 202 kann eine Anwendungsprogrammierschnittstelle (application programming interface - API) 204 und ein OVTP-Protokoll 205 beinhalten, das eine Vielzahl von Netzwerksoftwareschichten aufweist, wie etwa unter anderem ein Anwendungsrouting 206, eine Sitzungszustandsmaschine 208, eine Funktionsdefinition 210, eine Nachrichtenratensteuerung 212 und einen CAN-Treiber 214.
Hinsichtlich des CAN kann ein CAN-Nachrichterahmen eine Vielzahl von Feldern beinhalten, wie etwa ein Rahmenstartfeld (start of frame field - SOF-Feld), ein Arbitrierungsfeld, ein Steuerfeld, ein Datenfeld, ein Feld zur zyklischen Redundanzprüfung (cyclic redundancy check - CRC) und ein Rahmenendefeld (end of frame field - EOF-Feld). Das Arbitrierungsfeld kann eine Bitfolge für eine CAN-Nachrichtenkennung und ein Bit, das eine Nachrichtenpriorität definiert, beinhalten. Das Steuerfeld kann Daten beinhalten, die die Größe des Datenfelds definieren. Die ECUs 104 und/oder die Backbone-Steuerungen 106, die einen gegebenen Nachrichtenrahmen empfangen, können das Steuerfeld referenzieren, um festzustellen, wie viele Daten enthalten sind. Das Datenfeld kann eine vordefinierte Menge von Informationen beinhalten, wie etwa 8 Bytes, 64 Bytes oder eine beliebige andere Menge. In einigen Beispielen kann das Datenfeld zudem leer sein, z. B. 0 Bytes Informationen beinhalten, und einen Remote-Rahmen definieren, der eine Anforderung eines Datenrahmens umfasst. Andere Möglichkeiten für eine Größe und einen Wert des Datenfelds werden ebenfalls in Erwägung gezogen. Das CRC-Feld kann dabei helfen, Datenintegrität bereitzustellen, und das EOF-Feld kann dem Bus des Fahrzeugs 102 eine Benachrichtigung bereitstellen, dass die Nachricht vollständig ist.
Das Arbitrierungsfeld ist für eine bestimmte Nachricht festgelegt. Jede Nachricht weist eine eindeutige Nachrichtenkennung auf, obgleich mehrere der gleichen Nachrichten über das CAN gesendet werden können. In einem Beispiel kann eine CAN-Datenbank Definitionen aller Nachrichten für einen bestimmten Bus speichern. Die ECUs 104 und die Backbone-Steuerungen 106 in dem Netzwerk können dazu konfiguriert sein, zum Decodieren der empfangenen Nachrichtenrahmen auf die CAN-Datenbank zuzugreifen.
Die Prioritätskennung des Arbitrierungsfelds kann ein Bit zur Fernübertragungsanforderung (remote transmission request - RTR) beinhalten. Der Umstand, dass das RTR-Bit einen dominanten Zustand aufweist, kann einen gegebenen Nachrichtenrahmen als Datenrahmen kennzeichnen, und der Umstand, dass das RTR-Bit einen rezessiven Zustand aufweist, kann einen gegebenen Nachrichtenrahmen als Remote-Rahmen kennzeichnen. Die Backbone-Steuerung 106 kann den Remote-Rahmen, in dem ein Datenrahmen angefordert wird, der die gleiche Nachrichtenkennung aufweist wie der Remote-Rahmen, an die ECU 104 senden. Das Gateway 108 kann dementsprechend dazu konfiguriert sein, festzustellen, dass ein gegebener Datenrahmen (z. B. Nachrichtenrahmen, dessen RTR-Bit sich in einem dominanten Zustand befindet), der von der Ursprungssteuerung empfangen wird und zum Empfang durch die Zielsteuerung beabsichtigt ist, als Reaktion auf einen zuvor übertragenen Remote-Rahmen (z. B. Nachrichtenrahmen, dessen RTR-Bit sich in einem rezessiven Zustand befindet und dessen Nachrichtenkennung mit der Nachrichtenkennung des Datenrahmens übereinstimmt) gesendet wird.
In einem Beispiel kann das Datenfeld eines gegebenen CAN-Nachrichtenrahmens 8 Bytes lang sein und daher das Senden von Nachrichtenrahmen begrenzen, die länger als eine kurze Zeichenfolge oder eine einzelne große Zahl sind. Die CAN-Nachrichten, die eine Datengröße definieren, die größer als das Datenfeld ist, können in eine Vielzahl von CAN-Nachrichtenrahmen aufgeteilt werden. Die einzelnen CAN-Nachrichtenrahmen können Werte und Bitpositionen innerhalb der ursprünglichen CAN-Nachricht beinhalten. Die ECU 104 und die Backbone-Steuerung 106 können dazu konfiguriert sein, als Reaktion darauf, dass die CAN-Nachrichtenrahmen empfangen werden, die CAN-Datenbank dazu aufzufordern, die Position von jedem der Rahmen in der CAN-Message festzustellen.
Nun wird insbesondere auf OVTP Bezug genommen, wobei jede der Vielzahl von Anwendungen 216 (im Allgemeinen als die Elemente 216-A bis 216-C gezeigt) der API 204 Softwareanweisungen beinhalten kann, die dazu konfiguriert sind, durch einen Prozessor (nicht gezeigt) der Steuerung 104, 106 ausgeführt zu werden. In einem Beispiel kann die Anwendung 216 dazu konfiguriert sein, Daten zu empfangen, die durch einen Sensor erfasst werden, der mit den ECUs 104, 106 verbunden ist oder in Kommunikation steht, und die empfangenen Daten unter Verwendung einer CAN-Nachricht, die z. B. eine 29-bit-Nachrichtenkennung 220 beinhaltet, an eine andere der ECUs 104, 106 zu senden. Die API 204 ist dadurch dazu konfiguriert, CAN-Kommunikation zwischen den Anwendungen 216, die für die ECUs 104, 106 spezifisch sind, und denjenigen der anderen ECUs 104, 106 des Fahrzeugs 102 sowie mit einer oder mehreren Vorrichtungen (nicht gezeigt), die von dem Fahrzeug 102 entfernt sind, zu erleichtern. In einem anderen Beispiel kann die API 204 ferner dazu konfiguriert sein, den CAN-Kommunikationsdatenfluss zu und von den Anwendungen 216 unter Verwendung einer Anwendungssicherheitsschicht 218 zu sichern.
Die Anwendungen 216, die das OVTP-Protokoll 205 verwenden, können dazu konfiguriert sein, CAN-Nachrichtenrahmen zu senden und zu empfangen, die eine Vielzahl von Feldern beinhalten, wie etwa unter anderem das SOF-Feld, das Arbitrierungsfeld, das Steuerfeld, das Datenfeld, das CRC-Feld, das ACK-Feld und das EOF-Feld. Das Arbitrierungsfeld eines erweiterten CAN-Nachrichtenrahmens kann die 29-bit-Nachrichtenkennung 220 beinhalten und kann priorisieren, welche der Knoten, die eine Nachricht zu senden versuchen, den Bus des Fahrzeugs 102 steuern.
In einem Beispiel kann die Kennung 220 eine Ursprungssteuerungskennung 224, eine Zielsteuerungskennung 226, eine Ursprungsnetzkennung 228 und eine Prioritätskennung 230 umfassen. Die Ursprungssteuerungskennung 224 kann die ECU 104, 106 definieren, die die Nachricht sendet, z. B. die Ursprungs-ECU 104, die Ziel-ECU-Kennung 226 kann die ECUs 104, 106 definieren, für die die Nachricht bestimmt ist, z. B. die Ziel-ECU 104, die Ursprungsnetzkennung 228 kann das Ursprungsnetz definieren, wo die Ursprungs-ECU 104 angeordnet ist, und die Prioritätskennung 230 kann eine Priorität des Übertragens einer gegebenen CAN-Nachricht an die Ziel-ECU 104 in Bezug auf ein oder mehrere Steuersignale des Fahrzeugs 102 definieren.
Die Prioritätskennung 230 kann zum Beispiel die Priorität der Nachrichten in Bezug auf die Diagnose- und Steuernachrichten des Fahrzeugs 102 definieren. Als ein Beispiel kann der Umstand, dass die Prioritätskennung 230 einen dominanten Zustand aufweist, einen gegebenen Nachrichtenrahmen als Datenrahmen kennzeichnen, und der Umstand, dass die Prioritätskennung 230 einen rezessiven Zustand aufweist, einen gegebenen Nachrichtenrahmen als Remote-Rahmen kennzeichnen. Das Gateway 108 kann dementsprechend dazu konfiguriert sein, festzustellen, ob ein gegebener Nachrichtenrahmen ein Datenrahmen, z. B. Nachrichtenrahmen, dessen RTR-Bit sich in einem dominanten Zustand befindet, oder ein Remote-Rahmen, z. B. Nachrichtenrahmen, dessen RTR-Bit sich in einem rezessiven Zustand befindet, ist. Das Gateway 108 kann zudem dazu konfiguriert sein, auf Grundlage einer Kombination aus dem Zustand der Prioritätskennung 230 und dem Detektieren einer Übereinstimmung zwischen entsprechenden Nachrichtenkennungen des Remote- und Datenrahmens festzustellen, dass ein gegebener Datenrahmen als Reaktion auf einen zuvor übertragenen Remote-Rahmen gesendet worden ist.
Die Anwendungen 216 der ECUs 104 können als einige Beispiele Folgendes beinhalten: eine Anwendung über eine Luftschnittstelle (over-the-air - OTA), die eine Interpretation von Nachrichten ermöglicht, die unter dieser Anwendung als OTA-Softwareaktualisierungsnachrichten geroutet werden, und die Nachrichten zu einer entsprechenden OTA-fähigen Anwendung der Steuerung 104, 106 routet, eine PARSED-Anforderung-Antwort-Anwendung, die es jeder ECU 104, 106 ermöglicht, als Verarbeitungs- und Berichterstattungssystem für effiziente Datenhochladenachrichten Nachrichten zu interpretieren, die unter dieser Anwendung geroutet werden, und die Nachrichten an eine entsprechende Anwendung zur Übermittlung routet, eine PARSED-Push-Anwendung, die die funktionsfähige Übertragung von Daten auf Grundlage eines internen Ereignisses der ECU 104, 106 beinhalten kann und nur dann durchgeführt werden kann, wenn die PARSED-Anwendung korrekt durch die Anforderung-Antwort-Komponente der PARSED-Anwendung konfiguriert worden ist.
Die Ursprungs-ECU-Kennung 224 kann ferner eine Herkunfts-ECU 104, 106 für die OVTP-Nachricht definieren. In einem Beispiel können die Ursprungs-ECU-Kennungen 224 ferner ECU-Kennungen definieren, die in einer Routingtabelle gespeichert sind, die durch das Gateway 108 geführt wird. Die Ursprungs-ECU-Kennung 224 kann ermöglichen, dass mehrere Ursprungs-ECUs 104 mit mehreren Ziel-ECUs 104 gleichzeitig Nachrichtenrahmen austauschen.
Die Zielsteuerungskennung 226 kann die ECUs 104, 106 definieren, für die die OVTP-Nachricht beabsichtigt ist. In einem Beispiel kann für Nachrichten, die von einer gegebenen ECU 104, 106 stammen, die Ziel-ECU-Kennung 226 als die Ziel-ECU 104 definiert sein, die die Informationen empfängt, die übertragen werden. In einem anderen Beispiel können die Ziel-ECU-Kennungen 226 ferner ECU-Kennungen definieren, die in der Routingtabelle 208 gespeichert sind. Die Einbeziehung dieses Parameters kann ermöglichen, dass ein numerischer Wert zum Hardware-Routing auf gesteuerte Weise auf Softwareabstraktionsschichten angewendet wird. Als ein Beispiel kann die ECU 104, 106, die die CAN-Nachricht detektiert, die Ziel-ECU-Kennung 226 in der Bitübertragungsschicht referenzieren, um zu bestimmen, ob die detektierte CAN-Nachricht für diese oder für eine andere ECU 104 beabsichtigt ist, wodurch verhindert wird, dass die Schichten des Protokolls 205 über der Bitübertragungsschicht die detektierte CAN-Nachricht verarbeiten müssen, um die beabsichtigte Empfänger-ECU 104, 106 zu bestimmen.
Zum Beispiel kann ein Paar von ECUs 104, 106 an dem Fahrzeug 102, wie etwa die ADAS 104-E und die TCU 106-A, jeweils mit einem drahtlosen Netzwerk verbunden sein und dazu konfiguriert sein, unter Verwendung von CAN-Nachrichtenaustausch zu kommunizieren. Jede der ECUs 104, 106 kann eine eindeutige Position eines Teilnetzes 110 und/oder Backbone 112 darstellen, die eine eindeutige Netzwerkadresse definiert. Die ECUs 104, 106 können dementsprechend Nachrichten gleichzeitig senden und empfangen, ohne dass Konflikte bei der Nachrichtenübertragung über den physischen Draht des Netzwerks eintreten. Dies kann zudem die Hinzufügung der verbundenen ECUs 104, 106 ermöglichen, ohne dass eine Umgestaltung der Architektur erforderlich ist.
Das OVTP-Protokoll 205 kann Anforderungsadressierung verwenden, sodass eine gegebene ECU 104, 106 eine empfangene Anforderung gemäß einem oder mehreren vordefinierten Parametern interpretieren kann, die in der Anforderung enthalten sind„ z. B. einem Remote-Rahmen, der ein RTR-Bit in einem rezessiven Zustand beinhaltet und eine Anforderung eines entsprechenden Datenrahmens angibt, der das RTR-Bit in einem dominanten Zustand und die gleiche Nachrichtenkennung beinhaltet. In einem Beispiel kann das an dem ECU-Stapel definierte Protokoll 205 ferner dazu konfiguriert sein, eine Anforderung zu einer bestimmten Anwendung 216 der ECU 104, 106 zu routen, an die die Anforderung gerichtet ist (oder die die Anforderung übermitteln wird).
Die Sitzungszustandsmaschine 208 kann dazu konfiguriert sein, unsichere oder fehlerhaft verschlüsselte Anforderungen zurückzuweisen, um zu ermöglichen, dass die ECU 104, 106 Ressourcen freigibt, die für PARSED oder OTA zu anderen Anwendungen in Verwendung sein können, da eine Sitzung nicht aktiv ist. Die Verwendung der Zustandsmaschine 208 kann dementsprechend ermöglichen, dass die Bandbreitennutzung des Netzwerks des Fahrzeugs 102 ferngesteuert wird. Die Verwendung der Zustandsmaschine 208 kann ferner eine Handshake-Anforderung bereitstellen, sodass der Server bestätigen kann, dass der Client wach und zum Empfangen von Daten bereit ist.
Die Funktionsdefinitionen 210 können Funktionen definieren, die durch verschiedene Schemata verwendet werden, die sich die 29-bit-Nachrichtenkennung 220 zunutze machen. Zum Beispiel weisen unter anderem Aktualisierungen über eine Luftschnittstelle (OTA) einen definierten Satz von verfügbaren Funktionen auf, und diese Funktionsdefinitionsbits können eine Funktion referenzieren, die einer Nachricht zugeordnet ist. Der Abschnitt zur Nachrichtenratensteuerung 212 kann dazu konfiguriert sein, die Übertragungsgeschwindigkeit zu steuern, mit der der eine oder die mehreren CAN-Rahmen, die eine gegebene OVTP-Nachricht definieren, übertragen werden können. Der Abschnitt zur Nachrichtenratensteuerung 212 kann dementsprechend eine maximale Bandbreite steuern, die während einer gegebenen Übertragung verwendet wird.
Eine gegebene Datennachricht, die durch das Gateway 108 empfangen wird, kann dementsprechend die Ursprungssteuerungskennung 224, z. B. 10 Bits der 29-bit-Nachrichtenkennung 220, die Ziel-ECU-Kennung 226, z. B. 10 Bits der 29-bit-Nachrichtenkennung 220 und die Prioritätskennung 230, z. B. 3 Bits der 29-bit-Nachrichtenkennung 220, beinhalten. Das OVTP-Protokoll 205 kann ferner den CAN-Treiber 214 beinhalten, der dazu konfiguriert ist, CAN-Nachrichtenübermittlung durchzuführen, womit ermöglicht wird, dass die ECU 104, 106 CAN-Nachrichten sendet und empfängt, sowie die CAN-Nachrichten per Push an den CAN-Bus des Fahrzeugs 102 zu übertragen.
Statt dass die Adressierungskomponenten wie in einigen Fällen fest codiert sind, können sie als Logikkonstrukte ausgestaltet sein und die Verwendung der 10 Ursprungsbits und der insgesamt 20 Ursprungs-/Zielbits erleichtern. Dies kann eine Anwendung ermöglichen, die ein vermaschtes Netzwerk für die Nachrichten der ECU 104, 106 über das gesamte Netzwerk ohne Konflikte bereitstellt. Dies kann sich zudem in Bezug auf andere Netzwerke die Bitübertragungsschichten der Gestaltung des CAN-Protokolls 205 zunutze machen, die mehrere Absender und Empfänger an dem gleichen physischen Draht ermöglichen können. Die Steuerung 104, 106, die die CAN-Nachricht detektiert, kann die Zielsteuerungskennung 226 in der Bitübertragungsschicht referenzieren, um zu bestimmen, ob die detektierte CAN-Nachricht für diese oder für eine andere ECU 104, 106 beabsichtigt ist, wodurch verhindert wird, dass die Protokollschichten über der Bitübertragungsschicht die detektierte CAN-Nachricht verarbeiten müssen, die für eine andere ECU 104, 106 beabsichtigt ist.
3 veranschaulicht einen beispielhaften Prozess 300 zum Durchführen der sicheren Schlüsselverteilung. In einem Beispiel kann der Prozess 300 unter Verwendung der Systemtopologie 100 und des OVTP-Protokolls 205, die vorstehend ausführlich erörtert sind, durchgeführt werden.
In Phase 1 kann unter Bezugnahme auf Aufgabe A1 ein EOL-Prüfwerkzeug das Schlüsselverteilungsprotokoll auslösen. Dies kann in einem Beispiel bei Vorprozessen erfolgen, wobei das EOL-Prüfwerkzeug eine Diagnoseanforderung an das Gateway 108 sendet. Bei Aufgabe A2 ruft das Gateway 108 als Reaktion auf den Empfang der Anforderung die Funktionen des HSM 114 als Generator für echte Zufallszahlen ab und verwendet die daraus resultierende zufällige Folge zum Erzeugen des Schlüssels K.
In Phase 2 leitet das Gateway 108 unter Bezugnahme auf Aufgabe B1 das Schlüsselverteilungsprotokoll ein und sendet die OVTP-Nachricht aus, um die UID der HSM/SHE 116 an einer nachgelagerten ECU 104 in einer vordefinierten Gruppe zum Empfangen von Schlüsseln anzufordern. Bei Aufgabe B2 packt die nachgelagerte ECU 104 die OVTP-Nachricht aus und leitet die UID-Anforderung unter Verwendung des SHE-Protokolls an ihre periphere HSM/SHE 116 weiter.
In Phase 3 packt das Gateway 108 unter Bezugnahme auf Aufgabe B3 die UID von einer ECU 104 aus. Unter Bezugnahme auf Aufgabe C1 bereitet das Gateway 108 nach dem Empfangen der UID von der ECU 104 eine Folge aus M1, M2 und M3 (oder kurz M123) unter Verwendung des SHE- Speicheraktualisierungsprotokolls vor. Die M123 ist eine Folge, die die UID der ECU 104, den Zielschlüsselslotindex und einen Autorisierungsschlüsselslotindex, die verschlüsselte Kopie des Schlüssels K und eine Nachrichtenauthentifizierungskennung aller dieser Objekte enthält. Damit wird ermöglicht, dass die ECU 104 den Schlüsselslot auf sichere Weise auf den Wert des Schlüssels K aktualisiert. Bei Aufgabe C2 packt das Gateway 108 die Folge in eine OVTP-Anforderungsnachricht ein und sendet die Folge in Richtung der Ziel-ECU 104.
In Phase 4 validiert die HSM/SHE 116 der Ziel-ECU 104 unter Bezugnahme auf Aufgabe C4 die Folge M123. Falls die Validierung erfolgreich ist, gibt die HSM/SHE 116 eine Verifizierungsfolge M45 aus, die mit dem neuen Schlüssel K berechnet wird. Bei Aufgabe C5 packt die Ziel-ECU 104 die Folge M45 in eine OVTP-Antwort ein und sendet die eingepackte Folge M45 an das Gateway 108 zurück.
In Phase 5 validiert das Gateway 108 unter Bezugnahme auf Aufgabe C6 die M45 aus der Antwortnachricht nach dem Auspacken des OVTP. Falls die Folge erfolgreich ist, bestätigt das Gateway 108, dass der Schlüssel K erfolgreich an dem gewünschten Schlüsselslot an der gewünschten ECU 104 injiziert worden ist. Dementsprechend aktualisiert das Gateway 108 bei Aufgabe C7 die KIST 118, um die erfolgreiche Zustellung des Schlüssels K anzugeben.
In Phase 6 wiederholt das Gateway 108 ferner unter Bezugnahme auf Aufgabe D1 Phase 2 bis 5, bis alle Schlüssel korrekt injiziert worden sind. Wenn die Schlüsselinjektion abgeschlossen worden ist, kann das EOL-Werkzeug 120 die FIN-UID-Zuordnung und die KIST 118 auslesen, um zu bestätigen, welches Fahrzeug 102 welche ECUs 104 aufweist, sowie um erneut zu überprüfen, dass die Schlüsselinjektion erfolgreich abgeschlossen worden ist.
4 veranschaulicht ein beispielhaftes Datenflussdiagramm 400 zum Durchführen der sicheren Schlüsselverteilung. In einem Beispiel kann das Datenflussdiagramm 400 gemäß dem Prozess 300 unter Verwendung der Systemtopologie 100 und des OVTP-Protokolls 205, die vorstehend ausführlich erörtert sind, funktionieren.
Bei L0 autorisiert das EOL-Werkzeug 120 die Schlüsselverteilung gemäß Aufgabe A1. Als Reaktion auf die Autorisierung führt das Gateway 108 Aufgabe A2 und B1 durch. Als Reaktion auf den Abschluss von Aufgabe A2 und B1 sendet das EOL-Werkzeug 120 eine Bestätigung der Autorisierung, die bei L1 durch das EOL-Werkzeug 120 empfangen wird.
Bei L2 sendet das Gateway 108 eine OVTP-UID-Anforderung an die Ziel-ECU 104. Als Reaktion auf den Empfang der Anforderung führt die ECU 104 Aufgabe B2 durch. Als Reaktion auf den Abschluss von Aufgabe B2 sendet die ECU 104 eine OVTP-Antwort, die bei L3 durch das Gateway 108 empfangen wird. Als Reaktion auf den Empfang der Antwort führt das Gateway 108 Aufgabe B3, C1 und C2 durch.
Bei L4 sendet das Gateway 108 eine OVTP-Schlüsselaktualisierungsanforderung an die Ziel-ECU 104. Als Reaktion auf den Empfang der Anforderung führt die ECU 104 Aufgabe C4 und C5 durch. Als Reaktion auf den Abschluss von Aufgabe C4 und C5 sendet die ECU 104 eine OVTP-Schlüsselaktualisierungsantwort, die bei L5 durch das Gateway 108 empfangen wird. Als Reaktion auf den Empfang der Antwort führt das Gateway 108 Aufgabe C6 und C7 durch.
Es ist beachten, dass unter Bezugnahme auf die veranschaulichte Aufgabe D1 die Betriebsabläufe L2, L3, L4 und L5 für jede der Ziel-ECUs 104, die Schlüssel empfangen sollen, wiederholt werden können. Es sollte angemerkt werden, dass die Schlüsselverteilung an die ECUs 104 in einigen Beispielen aufeinanderfolgend an eine ECU 104 nach der anderen durchgeführt werden kann. In anderen Beispielen kann sich die Schlüsselverteilung an die ECUs 104 jedoch überschneiden, sodass einige ECUs 104 bestimmte Aufgaben des Prozesses 300 gleichzeitig dazu durchführen, dass andere ECUs 104 Aufgaben des Prozesses 300 durchführen.
Bei L6 sendet das EOL-Werkzeug 120 einen Statusping an das Gateway 108. Als Reaktion auf den Ping führt das Gateway 108 Aufgabe E1 und F1 durch. Als Reaktion auf den Abschluss von Aufgabe A2 und B1 sendet das Gateway 108 bei L7 eine Abgeschlossen-Antwortnachricht an das EOL-Werkzeug 120.
Bei L8 sendet das EOL-Werkzeug 120 eine Anforderung für die FIN-UID-KIST 118 an das Gateway 108. Als Reaktion auf die Anforderung sendet das Gateway 108 die KIST 118 an das EOL-Werkzeug 120, die bei L9 an dem EOL-Werkzeug 120 empfangen wird. Das EOL-Werkzeug 120 kann dementsprechend die KIST 118 analysieren und sicherstellen, dass die sichere Schlüsselverteilung an die ECUs 104 erfolgreich durchgeführt worden ist.
Somit kann durch Verwenden der Systemtopologie 100, des OVTP-Protokolls 205, des Prozesses 300 und des Datenflusses 400 ein Kontrahent nicht dazu in der Lage sein, bei der Schlüsselgeneration an dem Gateway 108 oder an nachgelagerten ECUs 104, wenn Schlüssel empfangen und aktualisiert werden, Schlüssel zu lesen. Darüber hinaus kann der Kontrahent nicht dazu in der Lage sein, die Schlüssel in Erfahrung zu bringen, während sie über CAN/CAN-FD/Ethernet/etc. übertragen werden. Zusätzlich können die Schlüssel eine Entropie von 128 bit aufrechterhalten, die verhindert, dass der Kontrahent eine ausgiebige Suche des Schlüsselraums versucht. Noch ferner kann der Kontrahent nicht dazu in der Lage sein, Schlüssel in die nachgelagerte ECU 104 zu schreiben.
Hier beschriebene Rechenvorrichtungen, wie etwa die ECUs 104, die Backbone-Steuerungen 106, das Gateway 108 und das EOL-Werkzeug 120, beinhalten im Allgemeinen computerausführbare Anweisungen, wobei die Anweisungen durch eine oder mehrere Rechenvorrichtungen, wie etwa die vorstehend aufgelisteten, ausgeführt werden können. Computerausführbare Anweisungen können von Computerprogrammen zusammengestellt oder ausgewertet werden, die unter Verwendung vielfältiger Programmiersprachen und/oder -technologien erstellt worden sind, einschließlich unter anderem und entweder für sich oder in Kombination Java™, C, C++, C#, Visual Basic, JavaScript, Python, JavaScript, Perl, PL/SQL etc. Im Allgemeinen empfängt ein Prozessor (z. B. ein Mikroprozessor) Anweisungen, z. B. von einem Speicher, einem computerlesbaren Medium etc., und führt diese Anweisungen aus, wodurch er einen oder mehrere Prozesse durchführt, zu denen einer oder mehrere der hier beschriebenen Prozesse gehören. Derartige Anweisungen und andere Daten können unter Verwendung einer Vielfalt an computerlesbaren Medien gespeichert und übertragen werden.
Hinsichtlich der hier beschriebenen Prozesse, Systeme, Verfahren, Heuristiken etc. versteht es sich, dass die Schritte derartiger Prozesse etc. zwar als gemäß einer bestimmten Reihenfolge erfolgend beschrieben worden sind, derartige Prozesse jedoch so umgesetzt werden könnten, dass die beschriebenen Schritte in einer anderen Reihenfolge als der hier beschriebenen Reihenfolge durchgeführt werden. Es versteht sich ferner, dass bestimmte Schritte gleichzeitig durchgeführt, andere Schritte hinzugefügt oder bestimmte hier beschriebene Schritte weggelassen werden könnten. Mit anderen Worten dienen die Beschreibungen von Prozessen in dieser Schrift dem Zwecke der Veranschaulichung bestimmter Ausführungsformen und sollten keinesfalls dahingehend ausgelegt werden, dass sie die Patentansprüche einschränken.
Dementsprechend versteht es sich, dass die vorstehende Beschreibung veranschaulichend und nicht einschränkend sein soll. Viele Ausführungsformen und Anwendungen, bei denen es sich nicht um die bereitgestellten Beispiele handelt, werden beim Lesen der vorstehenden Beschreibung ersichtlich. Der Umfang sollte nicht unter Bezugnahme auf die vorstehende Beschreibung ermittelt werden, sondern unter Bezugnahme auf die beigefügten Patentansprüche gemeinsam mit dem vollständigen Umfang von Äquivalenten, zu denen derartige Patentansprüche berechtigt sind. Es wird erwartet und beabsichtigt, dass es zu den hier erörterten Technologien künftige Entwicklungen geben wird und dass die offenbarten Systeme und Verfahren in derartige künftige Ausführungsformen aufgenommen werden. Insgesamt versteht es sich, dass die Anmeldung modifiziert und variiert werden kann.
Allen in den Patentansprüchen verwendeten Ausdrücken sollen deren umfassendste nachvollziehbare Konstruktionen und deren allgemeine Bedeutungen zugeordnet werden, wie sie den mit den hier beschriebenen Technologien vertrauten Fachleuten bekannt sind, sofern hier kein ausdrücklicher Hinweis auf das Gegenteil erfolgt. Insbesondere ist die Verwendung der Singularartikel wie etwa „ein“, „eine“, „der“, „die“, „das“ etc. dahingehend auszulegen, dass eines oder mehrere der aufgeführten Elemente genannt wird bzw. werden, es sei denn, ein Patentanspruch enthält ausdrücklich eine gegenteilige Einschränkung.
Die Zusammenfassung der Offenbarung wird bereitgestellt, um dem Leser einen schnellen Überblick über den Charakter der technischen Offenbarung zu ermöglichen. Sie wird in der Auffassung eingereicht, dass sie nicht dazu verwendet wird, den Umfang oder die Bedeutung der Patentansprüche auszulegen oder einzuschränken. Zusätzlich geht aus der vorstehenden detaillierten Beschreibung hervor, dass verschiedene Merkmale zum Zwecke der Vereinfachung der Offenbarung in verschiedenen Ausführungsformen zusammengefasst sind. Dieses Offenbarungsverfahren soll nicht dahingehend ausgelegt werden, dass es eine Absicht widerspiegelt, dass die beanspruchten Ausführungsformen mehr Merkmale als ausdrücklich in jedem Patentanspruch genannt erfordern. Vielmehr liegt der Gegenstand der Erfindung in weniger als allen Merkmalen einer einzelnen offenbarten Ausführungsform, wie die folgenden Patentansprüche widerspiegeln. Somit werden die folgenden Patentansprüche hiermit in die detaillierte Beschreibung aufgenommen, wobei jeder Patentanspruch für sich als separat beanspruchter Gegenstand steht.
Während vorstehend beispielhafte Ausführungsformen beschrieben sind, sollen diese Ausführungsformen nicht alle möglichen Formen der Erfindung beschreiben. Vielmehr sind die in der Beschreibung verwendeten Ausdrücke beschreibende und nicht einschränkenden Ausdrücke, und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne vom Geist und Umfang der Offenbarung abzuweichen. Zusätzlich können die Merkmale verschiedener umsetzender Ausführungsformen miteinander kombiniert werden, um weitere Ausführungsformen der Erfindung zu bilden.

Claims

System, umfassend: ein Gateway, das ein Hardware-Sicherheitsmodul (hardware security module - HSM), das einen Hardware-Zufallszahlengenerator umsetzt, und einen nichtflüchtigen Speicher, der eine Schlüsselinjektionsstatustabelle (key injection status table - KIST) führt, beinhaltet und dazu programmiert ist, unter Verwendung des Zufallszahlengenerators generierte Schlüssel als Reaktion auf einen Auslöser zum Beginnen der Schlüsselverteilung, der von einem Werkzeug am Ende der Linie (end-of-line tool - EOL-Werkzeug) empfangen wird, an eine Vielzahl von elektronischen Steuereinheiten (electronic control units - ECUs) zu verteilen und die KIST als Reaktion auf den Abschluss der Schlüsselverteilung an das EOL-Werkzeug zu senden.
System nach Anspruch 1, wobei das Gateway ferner dazu programmiert ist, die KIST als Reaktion auf den Empfang einer Bestätigung von einer der Vielzahl von ECUs, dass einer der Schlüssel erfolgreich in einen Schlüsselslot der einen der Vielzahl von ECUs injiziert worden ist, zu aktualisieren.
System nach Anspruch 1, wobei das Gateway ferner zu Folgendem programmiert ist: Anfordern einer eindeutigen Kennung (unique identifier - UID) einer der Vielzahl von ECUs; Generieren eines Schlüssels unter Verwendung des Zufallszahlengenerators für die UID; Senden des Schlüssels an die eine der Vielzahl von ECUs; und Aktualisieren der KIST, um anzugeben, dass der Schlüssel an die UID der einen der Vielzahl von ECUs gesendet wurde.
System nach Anspruch 1, wobei das Gateway ferner dazu programmiert ist, einen Schlüssel unter Verwendung einer M123-Folge, die (i) eine UID der einen der Vielzahl von ECUs, (ii) einen Zielschlüsselslotindex der einen der Vielzahl von ECUs, in die der Schlüssel platziert werden soll, und (iii) eine verschlüsselte Kopie des Schlüssels beinhaltet, an eine der Vielzahl von ECUs zu senden.
System nach Anspruch 4, wobei das Gateway ferner dazu programmiert ist, als Reaktion auf die M123-Folge eine M45-Antwort zu empfangen, die eine Verifizierung der Platzierung des Schlüssels beinhaltet, die unter Verwendung des zu platzierenden Schlüssels berechnet wird.
System nach Anspruch 1, wobei das Gateway ferner dazu programmiert ist, die KIST als Reaktion auf den Empfang einer KIST-Anforderungsnachricht von dem EOL-Werkzeug zu senden.
Verfahren, umfassend: Senden eines unter Verwendung eines Hardware-Zufallszahlengenerators generierten Schlüssels in einer verschlüsselten Nachricht an eine elektronische Steuereinheit (ECU) eines Fahrzeugs als Reaktion darauf, dass eine eindeutige Kennung (UID) der ECU über einen Fahrzeugbus empfangen wird; und als Reaktion auf eine Erfolgsangabe von der ECU in einer zweiten verschlüsselten Nachricht Aktualisieren einer Schlüsselinjektionsstatustabelle (KIST), um anzugeben, dass der Schlüssel auf die ECU angewendet wurde.
Verfahren nach Anspruch 7, ferner umfassend: Anfordern einer zweiten eindeutigen Kennung (UID) einer zweiten ECU über den Fahrzeugbus; Generieren eines zweiten Schlüssels unter Verwendung des Hardware-Zufallszahlengenerators; Senden des zweiten Schlüssels in einer dritten verschlüsselten Nachricht an die zweite ECU; und als Reaktion auf eine Erfolgsangabe von der zweiten ECU in einer vierten verschlüsselten Nachricht Aktualisieren der KIST, um anzugeben, dass der zweite Schlüssel auf die zweite ECU angewendet wurde.
Verfahren nach Anspruch 8, ferner umfassend: Empfangen einer Statusping-Nachricht von einem Werkzeug am Ende der Linie (EOL-Werkzeug), und Senden der KIST an das EOL-Werkzeug als Reaktion auf den Abschluss der Schlüsselverteilung an die ECU und die zweite ECU.
Verfahren nach Anspruch 7, ferner umfassend Einleiten der Schlüsselverteilung an die ECU als Reaktion auf den Empfang einer Autorisierungsnachricht von einem Werkzeug am Ende der Linie (EOL-Werkzeug).
Verfahren nach Anspruch 7, ferner umfassend Einschließen (i) einer UID der ECU, (ii) eines Zielschlüsselslotindex der ECU, in die der Schlüssel platziert werden soll, und (iii) einer verschlüsselten Kopie des Schlüssels in die verschlüsselte Nachricht.
Verfahren nach Anspruch 11, ferner umfassend Empfangen einer Verifizierung der Platzierung des Schlüssels, die unter Verwendung des zu platzierenden Schlüssels berechnet wird, in der zweiten verschlüsselten Nachricht.
Verfahren nach Anspruch 7, ferner umfassend Anfordern der eindeutigen Kennung (UID) von der ECU.