DE102023123232A1

DE102023123232A1 - Fahrzeugnetzwerksicherheit

Info

Publication number: DE102023123232A1
Application number: DE102023123232.0A
Authority: DE
Inventors: Venkata Maruthe Ravikumara Sharma Chengalvala
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2022-08-30
Filing date: 2023-08-29
Publication date: 2024-02-29
Also published as: CN117676589A; US20240073201A1

Abstract

Als Reaktion auf ein Detektieren eines Auslöseereignisses kann ein Computer in einem Fahrzeug, wie etwa eine Gateway-Vorrichtung, eine statische Kennung einer elektronischen Steuereinheit (ECU) über ein Fahrzeugnetzwerk abrufen. Der Computer in dem Fahrzeug kann dann als Reaktion auf eine Anforderung an einen Servercomputer eine Salt-Zeichenfolge empfangen und eine temporäre ECU-Kennung für die ECU auf Grundlage der Salt-Zeichenfolge und der statischen Kennung erzeugen. Die temporäre ECU-Kennung kann dann dem Fahrzeugnetzwerk bereitgestellt werden.

Description

GEBIET DER TECHNIK
Diese Offenbarung betrifft ein Netzwerksicherheitssystem in einem Fahrzeug.
ALLGEMEINER STAND DER TECHNIK
Moderne Fahrzeuge beinhalten typischerweise mehrere elektronische Vorrichtungen. Zum Beispiel beinhalten Fahrzeuge typischerweise mehrere Rechenvorrichtungen, wie etwa elektronische Steuereinheiten (electronic control units - ECUs) oder dergleichen. Die Rechenvorrichtungen können miteinander und/oder mit anderen Fahrzeugvorrichtungen, z. B. Fahrzeugsensoren, über ein oder mehrere Fahrzeugkommunikationsnetzwerke kommunizieren. Zum Beispiel können ECUs in einem Fahrzeug über einen Controller-Area-Network(CAN)-Bus und/oder ein Ethernet-Netzwerk kommunizieren. Ferner können einige Rechenvorrichtungen in einem Fahrzeug über ein fahrzeuginternes Netzwerk, wie etwa eines der Vorstehenden, sowie über ein Weitverkehrsnetzwerk kommunizieren, um mit entfernten oder „Cloud“-Servern zu kommunizieren.
KURZDARSTELLUNG
Gemäß der vorliegenden Erfindung ist ein System bereitgestellt, das Folgendes aufweist: eine Gateway-Vorrichtung, die mit einem Fahrzeugnetzwerk verbindbar ist und einen Prozessor und einen Speicher beinhaltet, wobei der Prozessor zu Folgendem programmiert ist: als Reaktion auf ein Detektieren eines Auslöseereignisses, Abrufen einer statischen Kennung einer elektronischen Steuereinheit (ECU) über das Fahrzeugnetzwerk; Empfangen, als Reaktion auf eine Anforderung an einen Servercomputer, einer Salt-Zeichenfolge; Erzeugen einer temporären ECU-Kennung für die ECU auf Grundlage der Salt-Zeichenfolge und der statischen Kennung; und Bereitstellen der temporären ECU-Kennung an das Fahrzeugnetzwerk.
Gemäß einer Ausführungsform ist die Gateway-Vorrichtung ferner zu Folgendem programmiert: als Reaktion auf ein Detektieren des Auslöseereignisses, Anfordern und Empfangen einer zweiten Salt-Zeichenfolge von dem Servercomputer oder einem zweiten Servercomputer; Erzeugen einer temporären Anwendungsprogrammierschnittstellen(API)-Kennung für eine API, die in der ECU beinhaltet ist, auf Grundlage der temporären ECU-Kennung und der zweiten Salt-Zeichenfolge; und Bereitstellen der temporären API-Kennung an das Fahrzeugnetzwerk.
Gemäß einer Ausführungsform ist die API in der ECU und einer zweiten ECU beinhaltet.
Gemäß einer Ausführungsform ist die zweite ECU eine Teil-ECU der ECU.
Gemäß einer Ausführungsform beinhaltet die Anforderung an den Servercomputer die statische Kennung der ECU.
Gemäß einer Ausführungsform beinhaltet die Anforderung an den Servercomputer die statische Kennung der ECU und mindestens einer zweiten ECU.
Gemäß einer Ausführungsform ist die Gateway-Vorrichtung ferner dazu programmiert, mindestens eine zweite Salt-Zeichenfolge für mindestens eine zweite ECU als Reaktion auf die Anforderung zu empfangen.
Gemäß einer Ausführungsform beinhaltet die Anforderung an den Server eine Fahrzeugkennung zusätzlich zur statischen Kennung der ECU.
Gemäß einer Ausführungsform ist die ECU eine von einer Vielzahl von ECUs in dem Fahrzeug und ist die Gateway-Vorrichtung ferner dazu programmiert, jeweilige temporäre ECU-Kennungen für jeweilige ECUs in der Vielzahl von ECUs zu erzeugen.
Gemäß einer Ausführungsform ist die Gateway-Vorrichtung ferner zu Folgendem programmiert: Bestimmen, dass eine Dauer der temporären ECU-Kennung abgelaufen ist; Erlangen einer zweiten Salt-Zeichenfolge; Erzeugen einer neuen temporären ECU-Kennung auf Grundlage der zweiten Salt-Zeichenfolge; und Aktualisieren der temporären ECU-Kennung mit der neuen temporären ECU-Kennung.
Gemäß einer Ausführungsform ist das Auslöseereignis ein Zündung-EIN-Ereignis.
Gemäß einer Ausführungsform ist die Gateway-Vorrichtung ferner dazu programmiert, die temporäre ECU-Kennung zu erzeugen, wenn ein zweites Auslöseereignis detektiert wird.
Gemäß einer Ausführungsform ist die Erfindung ferner gekennzeichnet durch den Servercomputer, wobei der Servercomputer einen Prozessor und einen Speicher beinhaltet und zu Folgendem programmiert ist: als Reaktion auf das Empfangen der Anforderung, Erzeugen der Salt-Zeichenfolge und Senden der Salt-Zeichenfolge an die Computer-Gateway-Vorrichtung in dem Fahrzeug.
Gemäß einer Ausführungsform ist der Servercomputer ferner dazu programmiert, die temporäre ECU-Kennung von der Gateway-Vorrichtung zu empfangen und die temporäre ECU-Kennung zu speichern.
Gemäß einer Ausführungsform ist der Servercomputer ferner dazu programmiert, die temporäre ECU-Kennung in einer Anforderung zu beinhalten, um auf die ECU zuzugreifen.
Gemäß der vorliegenden Erfindung beinhaltet ein Verfahren: als Reaktion auf ein Detektieren eines Auslöseereignisses, Abrufen einer statischen Kennung einer elektronischen Steuereinheit (ECU) über ein Fahrzeugnetzwerk; Empfangen, als Reaktion auf eine Anforderung an einen Servercomputer, einer Salt-Zeichenfolge; Erzeugen einer temporären ECU-Kennung für die ECU auf Grundlage der Salt-Zeichenfolge und der statischen Kennung; und Bereitstellen der temporären ECU-Kennung an das Fahrzeugnetzwerk.
In einem Aspekt der Erfindung beinhaltet das Verfahren: als Reaktion auf das Detektieren des Auslöseereignisses, Anfordern und Empfangen einer zweiten Salt-Zeichenfolge von dem Servercomputer oder einem zweiten Servercomputer; Erzeugen einer temporären Anwendungsprogrammierschnittstellen(API)-Kennung für eine API, die in der ECU beinhaltet ist, auf Grundlage der temporären ECU-Kennung und der zweiten Salt-Zeichenfolge; und Bereitstellen der temporären API-Kennung an das Fahrzeugnetzwerk.
In einem Aspekt der Erfindung ist die ECU eine von einer Vielzahl von ECUs im Fahrzeug, wobei das Verfahren ferner Erzeugen jeweiliger temporärer ECU-Kennungen für jeweilige ECUs in der Vielzahl von ECUs umfasst.
In einem Aspekt der Erfindung beinhaltet das Verfahren: Bestimmen, dass eine Dauer der temporären ECU-Kennung abgelaufen ist; Erlangen einer zweiten Salt-Zeichenfolge; Erzeugen einer neuen temporären ECU-Kennung auf Grundlage der zweiten Salt-Zeichenfolge; und Aktualisieren der temporären ECU-Kennung mit der neuen temporären ECU-Kennung.
In einem Aspekt der Erfindung beinhaltet das Verfahren Erzeugen der temporären ECU-Kennung beim Detektieren eines zweiten Auslöseereignisses.
KURZE BESCHREIBUNG DER ZEICHNUNGEN

1 ist ein Blockdiagramm eines Sicherheitssystems eines Fahrzeugnetzwerks 104.
2 ist ein Blockdiagramm, das Fahrzeug-ECUs veranschaulicht, die APIs in einem Fahrzeugnetzwerk 104 beinhalten.
3 ist ein Blockdiagramm, das eine Fahrzeug-ECU veranschaulicht, die eine Teil-ECU beinhaltet.
4 ist ein Prozessablaufdiagramm, das einen beispielhaften Prozess zum Erzeugen einer temporären ECU-Kennung veranschaulicht.
5 ist ein Prozessablaufdiagramm, das einen beispielhaften Prozess zum Erzeugen einer temporären ECU-Kennung und einer temporären API-Kennung veranschaulicht.
6 ist ein Prozessablaufdiagramm, das einen beispielhaften Prozess für einen entfernten Server zum Erzeugen von Salt-Zeichenfolgen und Verwenden von temporären Kennungen veranschaulicht.

DETAILLIERTE BESCHREIBUNG
Unter Bezugnahme auf die 1 und 2 ist in einer beispielhaften Umsetzung eine Vielzahl von ECUs 106 mit einem Fahrzeugnetzwerk 104 verbunden. Ferner können jeweilige ECUs 106 eine oder mehrere Anwendungsprogrammierschnittstellen (application programming interfaces - APIs) beinhalten. Der Zugriff auf das Fahrzeugnetzwerk 104 und/oder die Kommunikation mit diesem, einschließlich in Bezug auf die ECUs 106 und/oder APIs 200, kann durch einen Computer der Gateway-Vorrichtung 108 gesteuert werden, der manchmal als Netzwerk-Gateway bezeichnet wird. Die vorliegende Offenbarung beinhaltet Techniken zum Verbessern der Sicherheit in Rechenvorrichtungen des Fahrzeugs 102, die ECUs 106 und/oder APIs 200 beinhalten, die in einer oder mehreren ECUs 106 beinhaltet sind. Verschiedene Hardware- und/oder Softwaremodule in einem Fahrzeug 102, d. h. Rechenmodule des Fahrzeugs 102, wie etwa die ECUs 106 und APIs 200, können durch statische Kennungen identifiziert werden, d. h. Kennungen, die sich typischerweise im Laufe der Zeit nicht ändern, z. B. von einem Zündzyklus des Fahrzeugs 102 zum nächsten. In dieser Schrift offenbarte Techniken können eine temporäre Kennung für ein Rechenmodul des Fahrzeugs 102 erzeugen, sodass eine Kennung für das Rechenmodul zu einem ersten Zeitpunkt nicht dieselbe ist wie eine Kennung für das Rechenmodul zu einem zweiten Zeitpunkt. Die Sicherheit des Fahrzeugnetzwerks 104 kann somit auf verschiedene Arten verbessert werden. Zum Beispiel kann es für einen Angreifer schwierig oder unmöglich sein, die temporäre Kennung zu erraten oder abzuleiten. Darüber hinaus erschwert die Verwendung der temporären Kennung nur für einen begrenzten Zeitraum das Ableiten oder Erraten der temporären Kennung für einen möglichen Angreifer. Ferner hätte ein Angreifer in dem äußerst unwahrscheinlichen Fall, dass eine temporäre Kennung erraten oder abgeleitet wurde, nur die begrenzte Zeit der temporären Kennung, um zu versuchen, diese auszunutzen.
Ein System umfasst eine Gateway-Vorrichtung, die mit einem Fahrzeugnetzwerk verbindbar ist und einen Prozessor und einen Speicher beinhaltet, wobei der Prozessor zu Folgendem programmiert ist: als Reaktion auf ein Detektieren eines Auslöseereignisses, Abrufen einer statischen Kennung einer elektronischen Steuereinheit (ECU) über das Fahrzeugnetzwerk; Empfangen, als Reaktion auf eine Anforderung an einen Servercomputer, einer Salt-Zeichenfolge; Erzeugen einer temporären ECU-Kennung für die ECU auf Grundlage der Salt-Zeichenfolge und der statischen Kennung; und Bereitstellen der temporären ECU-Kennung an das Fahrzeugnetzwerk.
Die Gateway-Vorrichtung kann ferner dazu programmiert sein, als Reaktion auf das Detektieren des Auslöseereignisses, eine zweite Salt-Zeichenfolge von dem Servercomputer oder einem zweiten Servercomputer anzufordern und zu empfangen; eine temporäre Anwendungsprogrammierschnittstellen(API)-Kennung für eine API, die in der ECU beinhaltet ist, auf Grundlage der temporären ECU-Kennung und der zweiten Salt-Zeichenfolge zu erzeugen; und die temporäre API-Kennung an das Fahrzeugnetzwerk bereitzustellen. Die API kann in der ECU und einer zweiten ECU beinhaltet sein. Die zweite ECU kann eine Teil-ECU der ECU sein.
Die Anforderung an den Servercomputer kann die statische Kennung der ECU beinhalten. Die Anforderung an den Servercomputer kann die statische Kennung der ECU und mindestens einer zweiten ECU beinhalten. Die Gateway-Vorrichtung kann ferner dazu programmiert sein, mindestens eine zweite Salt-Zeichenfolge für mindestens eine zweite ECU als Reaktion auf die Anforderung zu empfangen. Die Anforderung an den Server kann eine Fahrzeugkennung zusätzlich zur statischen Kennung der ECU beinhalten.
Die ECU kann eine von einer Vielzahl von ECUs in dem Fahrzeug sein und die Gateway-Vorrichtung kann ferner dazu programmiert sein, jeweilige temporäre ECU-Kennungen für jeweilige ECUs in der Vielzahl von ECUs zu erzeugen.
Die Gateway-Vorrichtung kann ferner dazu programmiert sein, zu bestimmen, dass eine Dauer der temporären ECU-Kennung abgelaufen ist; eine zweite Salt-Zeichenfolge zu erlangen; eine neue temporäre ECU-Kennung auf Grundlage der zweiten Salt-Zeichenfolge zu erzeugen; und die temporäre ECU-Kennung mit der neuen temporären ECU-Kennung zu aktualisieren.
Das Auslöseereignis kann ein Zündung-EIN-Ereignis sein.
Die Gateway-Vorrichtung kann ferner dazu programmiert sein, die temporäre ECU-Kennung zu erzeugen, wenn ein zweites Auslöseereignis detektiert wird.
Das System kann ferner den Servercomputer umfassen, wobei der Servercomputer einen Prozessor und einen Speicher beinhaltet und zu Folgendem programmiert ist: als Reaktion auf das Empfangen der Anforderung, Erzeugen der Salt-Zeichenfolge und Senden der Salt-Zeichenfolge an die Computer-Gateway-Vorrichtung in dem Fahrzeug. Der Servercomputer kann ferner dazu programmiert sein, die temporäre ECU-Kennung von der Gateway-Vorrichtung zu empfangen und die temporäre ECU-Kennung zu speichern. Der Servercomputer kann ferner dazu programmiert sein, die temporäre ECU-Kennung in einer Anforderung zu beinhalten, um auf die ECU zuzugreifen.
Ein Verfahren umfasst, als Reaktion auf ein Detektieren eines Auslöseereignisses, Abrufen einer statischen Kennung einer elektronischen Steuereinheit (ECU) über ein Fahrzeugnetzwerk; Empfangen, als Reaktion auf eine Anforderung an einen Servercomputer, einer Salt-Zeichenfolge; Erzeugen einer temporären ECU-Kennung für die ECU auf Grundlage der Salt-Zeichenfolge und der statischen Kennung; und Bereitstellen der temporären ECU-Kennung an das Fahrzeugnetzwerk.
Das Verfahren kann ferner, als Reaktion auf das Detektieren des Auslöseereignisses, Anfordern und Empfangen einer zweiten Salt-Zeichenfolge von dem Servercomputer oder einem zweiten Servercomputer; Erzeugen einer temporären Anwendungsprogrammierschnittstellen(API)-Kennung für eine API, die in der ECU beinhaltet ist, auf Grundlage der temporären ECU-Kennung und der zweiten Salt-Zeichenfolge; und Bereitstellen der temporären API-Kennung an das Fahrzeugnetzwerk umfassen.
Die ECU kann eine von einer Vielzahl von ECUs im Fahrzeug sein, wobei das Verfahren ferner Erzeugen jeweiliger temporärer ECU-Kennungen für jeweilige ECUs in der Vielzahl von ECUs umfasst.
Das Verfahren kann ferner Bestimmen, dass eine Dauer der temporären ECU-Kennung abgelaufen ist; Erlangen einer zweiten Salt-Zeichenfolge; Erzeugen einer neuen temporären ECU-Kennung auf Grundlage der zweiten Salt-Zeichenfolge; und Aktualisieren der temporären ECU-Kennung mit der neuen temporären ECU-Kennung umfassen. Das Verfahren kann ferner Erzeugen der temporären ECU-Kennung beim Detektieren eines zweiten Auslöseereignisses umfassen.
1 ist ein Blockdiagramm eines Fahrzeugnetzwerksicherheitssystems 100. Ein Fahrzeug 102 im Kontext dieser Offenbarung kann ein beliebiges geeignetes Fahrzeug sein, z. B. ein Personen- oder Nutzkraftwagen, wie etwa eine Limousine, ein Coupe, ein Truck, ein SUV, ein Crossover, ein Van, ein Minivan, ein Taxi, ein Bus usw. Ferner könnten, wenngleich diese Offenbarung Landfahrzeuge 102 beschreibt, die Systeme und Verfahren gleichermaßen in Bezug auf Wasser- oder Luftfahrzeuge 102 umgesetzt werden.
Ein Fahrzeug 102 beinhaltet ein Fahrzeugnetzwerk 104, d. h. ein digitales Netzwerk oder Paketnetzwerk, über das Nachrichten zwischen verschiedenen Vorrichtungen in dem Fahrzeug 102, wie etwa der Gateway-Vorrichtung 108 und/oder den ECUs 106, Sensoren 110, Aktoren, Komponenten 112, Kommunikationsmodul usw., ausgetauscht werden können. In Fällen, in denen eine Rechenvorrichtung, wie etwa die Gateway-Vorrichtung 108 oder eine ECU 106, tatsächlich eine Vielzahl von Vorrichtungen umfasst, könnte das Fahrzeugnetzwerk 104 zur Kommunikation zwischen derartigen Vorrichtungen verwendet werden.
In beispielhaften Umsetzungen kann ein Fahrzeugnetzwerk 104 ein Controller Area Network (CAN) beinhalten, in dem Nachrichten über einen CAN-Bus übermittelt werden, oder ein Local Interconnect Network (LIN), in dem Nachrichten über einen LIN-Bus übermittelt werden. Das Fahrzeugnetzwerk 104 kann ferner alternativ oder zusätzlich ein Ethernet-Netzwerk beinhalten. Zum Beispiel könnte die Gateway-Vorrichtung 108 eine Gateway-Vorrichtung 108 sein, die Nachrichten zwischen einem entfernten Server 118 und Vorrichtungen in dem Fahrzeug 102, wie etwa ECUs 106, die über einen CAN-Bus und/oder Ethernet kommunizieren, verwaltet. Noch ferner könnte das Fahrzeugnetzwerk 104 in einigen Umsetzungen ein Netzwerk beinhalten, in dem Nachrichten unter Verwendung anderer drahtgebundener Kommunikationstechnologien und/oder drahtloser Kommunikationstechnologien übermittelt werden, z. B. WiFi®, Bluetooth® usw. Zusätzliche Beispiele für Protokolle, die in einigen Umsetzungen zur Kommunikation über das Fahrzeugnetzwerk 104 verwendet werden können, beinhalten unter anderem Media Oriented System Transport (MOST), Time-Triggered Protocol (TTP) und FlexRay.
Wie ersichtlich ist, könnte das Fahrzeugnetzwerk 104 in einigen Umsetzungen eine Kombination aus mehreren Netzwerken, möglicherweise unterschiedlicher Arten, darstellen, die Kommunikation zwischen Vorrichtungen in dem Fahrzeug 102 unterstützen. Zum Beispiel kann das Fahrzeugnetzwerk 104 ein CAN, in dem einige Vorrichtungen in dem Fahrzeug 102 über einen CAN-Bus kommunizieren, und ein drahtgebundenes oder drahtloses lokales Netzwerk, in dem einige Vorrichtungen in dem Fahrzeug 102 gemäß Ethernet- oder Wi-Fi-Kommunikationsprotokollen kommunizieren, beinhalten.
Die ECUs 106 und die Gateway-Vorrichtung 108 sind jeweilige Rechenvorrichtungen, die jeweils einen Prozessor und einen Speicher beinhalten. Der Speicher beinhaltet eine oder mehrere Formen computerlesbarer Medien und in ihm sind Anweisungen gespeichert, die durch die jeweilige Rechenvorrichtung ausführbar sind, um verschiedene Vorgänge durchzuführen, einschließlich der in dieser Schrift offenbarten. Zum Beispiel kann eine Rechenvorrichtung ein generischer Computer mit einem Prozessor und einem Speicher, wie vorstehend beschrieben, sein und/oder eine ECU 106 oder eine Gateway-Vorrichtung 108 für eine spezifische Funktion oder einen Satz von Funktionen und/oder eine dedizierte elektronische Schaltung beinhalten, die eine ASIC (anwendungsspezifische integrierte Schaltung) beinhaltet, die für einen konkreten Vorgang hergestellt wird, z. B. eine ASIC zur Verarbeitung von Daten des Sensors 110 und/oder zur Kommunikation der Daten des Sensors 110. In einem weiteren Beispiel kann der Computer des Fahrzeugs 102 ein FPGA (feldprogrammierbares Gate-Array) beinhalten, bei dem es sich um eine integrierte Schaltung handelt, die so hergestellt ist, dass sie durch einen Benutzer konfigurierbar ist. Typischerweise wird eine Hardwarebeschreibungssprache, wie etwa VHDL (Very High Speed Integrated Circuit Hardware Description Language - Hardwarebeschreibungssprache für integrierte Schaltungen mit sehr hoher Geschwindigkeit), bei der elektronischen Entwurfsautomatisierung verwendet, um digitale Systeme und Mischsignalsysteme, wie etwa FPGA und ASIC, zu beschreiben. Zum Beispiel wird eine ASIC basierend auf VHDL-Programmierung hergestellt, die vor der Herstellung bereitgestellt wird, wohingegen logische Komponenten 112 im Inneren eines FPGA basierend auf VHDL-Programmierung konfiguriert sein können, die z. B. in einem Speicher gespeichert ist, der elektrisch mit der FPGA-Schaltung verbunden ist. In einigen Beispielen kann eine Kombination aus Prozessor(en), ASIC(s) und/oder FPGA-Schaltungen in einer Rechenvorrichtung beinhaltet sein.
Der Speicher einer Rechenvorrichtung kann von einer beliebigen geeigneten Art sein, z. B. Festplattenlaufwerke, Festkörperlaufwerke, Server 118 oder beliebige flüchtige oder nichtflüchtige Medien. Der Speicher kann Programmanweisungen, verschiedene Daten, wie etwa statische Kennungen oder dergleichen, wie nachstehend ausführlicher erörtert, und/oder gesammelte Daten, die von Fahrzeugsensoren 110 gesendet werden, speichern. Der Speicher kann eine von der Rechenvorrichtung getrennte Vorrichtung sein und die Rechenvorrichtung kann durch den Speicher gespeicherte Informationen über ein Netzwerk in dem Fahrzeug 102 abrufen, z. B. über einen CAN-Bus, ein drahtloses Netzwerk usw. Alternativ oder zusätzlich kann der Speicher Teil der Rechenvorrichtung sein.
Eine Rechenvorrichtung, z. B. eine ECU 106, kann eine Programmierung beinhalten, um eines oder mehrere von Bremsen, Antrieb, z. B. Steuerung der Beschleunigung des Fahrzeugs 102 durch Steuern von einem oder mehreren von einer Brennkraftmaschine, einem Elektromotor, Hybridmotor usw., Lenkung, Klimasteuerung, Innen- und/oder Außenbeleuchtung usw. des Fahrzeugs 102 zu betreiben, sowie um zu bestimmen, ob und wann der Computer derartige Vorgänge anstelle eines menschlichen Betreibers steuern soll. Zusätzlich kann eine Rechenvorrichtung im Fahrzeug 102 dazu programmiert sein, zu bestimmen, ob und wann ein menschlicher Fahrzeugführer derartige Vorgänge steuern soll.
Die Gateway-Vorrichtung 108 ermöglicht es Vorrichtungen an dem Fahrzeugnetzwerk 104, wie etwa den ECUs 106, mit Vorrichtungen außerhalb des Fahrzeugnetzwerks 104 zu kommunizieren, wie etwa einem Server 118, der mit dem Fahrzeug 102 über das Weitverkehrsnetzwerk 116 kommuniziert. Somit ist die Gateway-Vorrichtung 108 eine Rechenvorrichtung wie vorstehend beschrieben. Das Gateway kann über das Fahrzeugnetzwerk 104 Nachrichten an und von Vorrichtungen des Fahrzeugs 102, wie etwa die ECUs 106, senden und kann das Kommunikationsmodul 114 betätigen, um Nachrichten an und von Vorrichtungen außerhalb des Fahrzeugs 102, wie etwa einem Server 118, zu senden.
Ein Fahrzeug 102 beinhaltet typischerweise eine Vielfalt von Sensoren 110, die Daten über das Fahrzeugnetzwerk 104 bereitstellen. Ein Sensor 110 ist eine Vorrichtung, die eine oder mehrere Messungen eines oder mehrerer physischer Phänomene erlangen kann. Beispielhafte Sensoren 110 des Fahrzeugs 102 könnten Kameras, Kurzstreckenradar, Langstreckenradar, LIDAR und/oder Ultraschallwandler, Gewichtssensoren 110, Beschleunigungsmesser, Bewegungsdetektoren usw., d. h., Sensoren 110, beinhalten, um eine Vielfalt von Daten bereitzustellen. Um nur einige nicht einschränkende Beispiele bereitzustellen, könnten Daten des Sensors 110 Daten zum Bestimmen einer Position einer Komponente 112, eines Standorts eines Objekts, einer Geschwindigkeit eines Objekts, einer Art eines Objekts, einer Neigung einer Fahrbahn, einer Temperatur, eines Vorhandenseins oder einer Menge an Feuchtigkeit, eines Kraftstofffüllstands, einer Datenrate usw. beinhalten.
ECUs 106 und dergleichen können Programmierung beinhalten, um einem oder mehreren Aktoren zu befehlen, ein(e) oder mehrere Teilsysteme oder Komponenten 112 des Fahrzeugs 102 zu betreiben, wie etwa Bremsen, Antrieb oder Lenkung des Fahrzeugs 102. Das heißt, eine ECU 106 kann die Steuerung der Beschleunigung des Fahrzeugs 102 durch Steuern eines oder mehrerer von einer Brennkraftmaschine, einem Elektromotor, einem Hybridmotor usw. betätigen und/oder kann die Steuerung von Bremsen, Lenkung, Klimatisierung, Innen- und/oder Außenleuchten usw. betätigen.
Wie in 2 zu sehen ist, können verschiedene ECUs 106 eine oder mehrere APIs 200 beinhalten. Eine API 200 ist ein Satz von Computerprogrammanweisungen, die es einem Computer ermöglichen, eine Schnittstelle mit einem anderen Computer zu bilden, d. h. Anforderungen und/oder Daten von diesem zu empfangen und/oder Anforderungen und/oder Daten an diesen zu senden. ECUs 106 des Fahrzeugs 102 können bereitgestellt sein, um einem anderen Computer zu ermöglichen, verschiedene Vorgänge und/oder Daten anzufordern, wie etwa Telemetriedaten (z. B. Standort, Geschwindigkeit, Zündstatus, Diagnosedaten usw. eines Fahrzeugs 102), Deaktivieren oder Aktivieren eines Antrieb, einer Benachrichtigung, dass ein Sicherheitssystem 100 des Fahrzeugs 102 verletzt wurde, Zugriff auf ein Fahrzeugnetzwerk 104 und Steuerung von diesem, wie etwa eines Wi-Fi-Netzwerks, usw. Die ECUs 106 werden in dieser Schrift gemeinsam als ECUs 106 bezeichnet, aber in 2 werden die ECUs 106a-106e sind separat gekennzeichnet, um unterschiedliche der verschiedenen ECUs 106 zu veranschaulichen. Gleichermaßen werden die APIs 200 in dieser Schrift gemeinsam als APIs 200 bezeichnet, aber in 2 sind die APIs 200a-200l separat gekennzeichnet, um separate APIs 200 in den verschiedenen ECUs 106 zu veranschaulichen. Es ist anzumerken, dass eine API 200 in jeweiligen ECUs 106 dupliziert oder verteilt sein kann. Zum Beispiel könnte eine API 200 zum Unterstützen autonomer oder halbautonomer Vorgänge, die eine Steuerung der Lenkung sowie der Geschwindigkeit beinhalten, auf mehrere ECUs 106 verteilt sein. Ferner sind Szenarien möglich, in denen eine erste API 200 auf eine zweite API 200 zugreift, z. B. beinhaltet die erste API 200 Programmierung zum Aufrufen einer Funktion der zweiten API 200.
Noch ferner könnte, wie in 3 veranschaulicht, eine erste ECU 106z, die als Teil-ECU bezeichnet werden könnte, in einer zweiten ECU 106a beinhaltet sein, die die APIs 200a, 200b, 200c beinhaltet. Die Teil-ECU könnte ihren eigenen Satz von APIs 200x, 200y beinhalten.
Die Gateway-Vorrichtung 108 (und möglicherweise andere Rechenvorrichtungen des Fahrzeugs 102) können zur Kommunikation über ein Kommunikationsmodul 114 oder eine Schnittstelle mit Vorrichtungen außerhalb des Fahrzeugs 102, z. B. durch Fahrzeug 102 zu Fahrzeug 102 (V2V), Fahrzeug zu Infrastruktur oder Fahrzeug zu allem (V2X), Fahrzeug zu allem mit Mobilfunkkommunikation (C-V2X), mit einem anderen Fahrzeug 102, mit einem Infrastrukturelement, typischerweise über direkte Funkfrequenzkommunikation, und/oder, typischerweise über das Weitverkehrsnetzwerk 116, mit einem oder mehreren entfernten Servern 118 konfiguriert sein. Das Kommunikationsmodul 114 könnte einen oder mehrere Mechanismen beinhalten, durch die die Computer von Fahrzeugen 102 kommunizieren können, einschließlich einer beliebigen gewünschten Kombination aus drahtlosen (z. B. Mobilfunk-, Drahtlos-, Satelliten-, Mikrowellen- und Hochfrequenz-) Kommunikationsmechanismen und einer beliebigen gewünschten Netzwerktopologie oder - topologien, wenn eine Vielzahl von Kommunikationsmechanismen genutzt wird. Beispielhafte Kommunikationen, die über das Kommunikationsmodul 114 bereitgestellt werden, z. B. zum Kommunizieren mit einem Server 118, können Mobilfunk, Bluetooth, IEEE 802.11, Dedicated Short Range Communications (DSRC), Mobilfunk-V2X (CV2X), MQTT, gRPC und dergleichen beinhalten.
Das Weitverkehrsnetzwerk 116 kann einen oder mehrere Mechanismen beinhalten, durch die das Kommunikationsmodul 114 beispielsweise mit einem entfernten Server 118 kommunizieren kann. Dementsprechend kann das Weitverkehrsnetzwerk 116 eine oder mehrere von verschiedenen drahtgebundenen oder drahtlosen Kommunikationsmechanismen beinhalten, die eine beliebige gewünschte Kombination aus drahtgebundenen (z. B. Kabel- und Faser-) und/oder drahtlosen (z. B. Mobilfunk-, Drahtlos-, Satelliten-, Mikrowellen- und Hochfrequenz-) Kommunikationsmechanismen und eine beliebige gewünschte Netzwerktopologie oder -topologien, wenn mehrere Kommunikationsmechanismen genutzt werden, beinhalten. Beispielhafte Kommunikationsnetzwerke beinhalten drahtlose Kommunikationsnetzwerke, z. B. unter Verwendung von Bluetooth, Bluetooth Low Energy BLE, IEEE 802.11, V2V, V2X, CV2X, DSRC, lokale Netzwerke LAN und/oder das Internet.
Der entfernte Server 118 ist eine Rechenvorrichtung, wie vorstehend beschrieben. Manchmal kann der entfernte Server 118 als „Cloud“-Server bezeichnet werden, da er von dem Fahrzeug 102 entfernt ist und über das Weitverkehrsnetzwerk 116 darauf zugegriffen wird.
Wie vorstehend angemerkt, ist die Gateway-Vorrichtung 108 mit dem Fahrzeugnetzwerk 104 verbindbar, um mit anderen Vorrichtungen, wie etwa ECUs 106, in dem Fahrzeugnetzwerk 104 zu kommunizieren. Die Gateway-Vorrichtung 108 kann als Reaktion auf das Detektieren eines Auslöseereignisses in dem Fahrzeugnetzwerk 104 temporäre Kennungen für die ECUs 106 und/oder APIs 200 erzeugen. Zum Beispiel kann ein Fahrzeugnetzwerk 104 ein Zündung-EIN-Ereignis an Vorrichtungen in einem Fahrzeug 102 senden. In einem anderen Beispiel, wie nachstehend erörtert, könnte ein Auslöseereignis ein Ablauf der Zeitdauer sein. In noch einem weiteren Beispiel könnte ein Auslöseereignis eine Benutzereingabe zum Zugreifen auf eine Anwendung über eine Benutzervorrichtung, die mit einem Fahrzeugcomputer verbunden ist, oder über eine Mensch-Maschine-Schnittstelle (human machine interface - HMI) in dem Fahrzeug sein, z. B. durch Bereitstellen einer Eingabe über ein Mikrofon oder einen Touchscreen. Beim Empfangen der Benutzereingabe könnte ein Fahrzeugcomputer bestimmen, dass auf eine oder mehrere APIs 200, die sich in einer oder mehreren ECUs 106 befinden, zugegriffen werden muss. Eine derartige Benutzereingabe könnte auch dann empfangen werden, wenn sich ein Fahrzeug in einem Zündung-AUS-Zustand befindet, z. B., wenn ein Benutzer zum Beispiel eine Software-Aktualisierung per Funk auslöst. In noch einem anderen Beispiel könnte ein Auslöseereignis sein, dass ein Computer in dem Fahrzeug, wie etwa die Gateway-Vorrichtung 108, eine Aufwecknachricht empfängt, z. B. unter Verwendung eines Simple Message Service (SMS).
Beim Detektieren des Auslöseereignisses, z. B. des Zündung-EIN-Ereignisses, kann das Gateway jeweilige statische Kennungen einer oder mehrerer elektronischer Steuereinheiten (ECU) über das Fahrzeugnetzwerk 104 abrufen. Zum Beispiel könnte die statische Kennung einer ECU 106 eine elektronische Seriennummer (ESN) oder dergleichen sein, die die ECU 106 in dem Fahrzeugnetzwerk 104 identifiziert. Das Gateway könnte eine Tabelle oder dergleichen von ECUs 106 und jeweiligen Kennungen führen. Alternativ oder zusätzlich könnten sich die ECUs 106 gegenüber dem Gateway in dem Fahrzeugnetzwerk 104 identifizieren, z. B. als Reaktion auf ein Netzwerkaufweck- und/oder Zündung-EIN-Ereignis des Fahrzeugs 102. Auf die ECUs 106 kann dann über das Fahrzeugnetzwerk 104 gemäß ihren jeweiligen Kennungen zugegriffen werden. Diese Kennungen werden als statische Kennungen bezeichnet, da sie typischerweise in einem Festwertspeicher gespeichert sind und sich nicht ändern. Gleichermaßen können jeweilige APIs 200 statische Kennungen aufweisen, die in einer Tabelle oder dergleichen der Gateway-Vorrichtung 108 gespeichert sind.
Durch Betätigen des Kommunikationsmoduls 114 des Fahrzeugs 102 kann die Gateway-Vorrichtung 108 über ein Weitverkehrsnetzwerk 116 mit einem Computer des entfernten Servers 118 in Kommunikation stehen. Beim Identifizieren einer oder mehrerer statischer ECU-Kennungen kann die Gateway-Vorrichtung 108 den entfernten Server 118 auffordern, eine Salt-Zeichenfolge bereitzustellen. Eine Salt-Zeichenfolge ist eine zufällig oder pseudozufällig erzeugte Zeichenfolge, die mit einer anderen Zeichenfolge kombiniert oder verkettet, z. B. dieser vorangestellt oder an diese angehängt werden kann. In Beispielen in dieser Schrift werden statischen ECU-Kennungen jeweilige Salt-Zeichenfolgen vorangestellt oder angehängt. Der Server 118 kann eine oder mehrere angeforderte Salt-Zeichenfolgen als Reaktion auf eine Anforderung von der Gateway-Vorrichtung 108 an die Gateway-Vorrichtung 108 zurücksenden. Beim Empfangen der einen oder der mehreren Salt-Zeichenfolgen kann die Gateway-Vorrichtung 108 dann jeweilige temporäre ECU-Kennungen auf Grundlage der Salt-Zeichenfolge und der statischen Kennung für die jeweilige ECU 106 erzeugen. Zum Beispiel können die Salt-Zeichenfolge und die statische ECU-Kennung verkettet werden, z. B. kann die Salt-Zeichenfolge an die statische ECU-Kennung angehängt werden. Die Gateway-Vorrichtung 108 kann eine weitere Verarbeitung durchführen, um die Sicherheit der temporären ECU-Kennung zu verbessern. Zum Beispiel kann Hashen unter Verwendung eines geeigneten Algorithmus, wie etwa SHA256/512, angewendet werden, um die temporäre ECU-Kennung weiter zu transformieren und zu verschleiern und um es für einen Angreifer noch schwieriger zu machen, die temporäre ECU-Kennung zurück zu entwickeln, zu erraten oder abzuleiten. Die temporäre ECU-Kennung kann dann dem Fahrzeugnetzwerk 104 bereitgestellt werden. Das heißt, die Gateway-Vorrichtung 108 kann eine Tabelle oder dergleichen von temporären ECU-Kennungen speichern, die den jeweiligen ECUs 106 in der Tabelle oder dergleichen zugeordnet sind, die statische Kennungen der ECU 106 angibt. Dann, beim Empfangen einer Anforderung von einer Vorrichtung außerhalb des Fahrzeugs 102, z. B. von einem Server 118 oder von einer Benutzervorrichtung, wie etwa einem Smartphone oder dergleichen, die eine temporäre Kennung von dem Server 118 empfangen hat, kann die Gateway-Vorrichtung 108 Zugriff auf die jeweilige ECU 106 gewähren.
Die Gateway-Vorrichtung 108 kann ferner eine oder mehrere temporäre Kennungen der API 200 erzeugen. Zum Beispiel kann die Gateway-Vorrichtung 108 als Reaktion auf das Detektieren des Auslöseereignisses eine oder mehrere zweite Salt-Zeichenfolgen von dem Computer des Servers 118 oder einem zweiten Computer des Servers 118 anfordern und empfangen. Beim Empfangen einer Salt-Zeichenfolge für eine API 200 kann die Gateway-Vorrichtung 108 dann eine temporäre Anwendungsprogrammierschnittstellen(API)-Kennung für eine API 200, die in einer ECU 106 beinhaltet ist, auf Grundlage der temporären ECU-Kennung für diese ECU 106 und die zweite Salt-Zeichenfolge erzeugen. Die Gateway-Vorrichtung 108 kann dann die temporäre Kennung der API 200 in dem Fahrzeugnetzwerk 104 bereitstellen, z. B. wie vorstehend zum Bereitstellen von temporären ECU-Kennungen beschrieben.
Eine Anforderung von der Gateway-Vorrichtung 108 an einen Server 118 für eine Salt-Zeichenfolge beinhaltet typischerweise eine Kennung des Fahrzeugs 102, z. B. eine Identifikationsnummer (VIN) des Fahrzeugs 102, und jeweilige statische Kennungen einer oder mehrerer ECUs 106. Der Server 118 könnte dann die empfangenen statischen Kennungen in Verbindung mit der Kennung des Fahrzeugs 102 speichern. Ferner kann die Gateway-Vorrichtung 108 dem Server 118 erzeugte temporäre Kennungen für die ECUs 106 und/oder APIs 200 zusammen mit der Kennung des Fahrzeugs 102 und den jeweiligen statischen Kennungen bereitstellen, sodass der Server 118 dann temporäre Kennungen zum Zugreifen auf die jeweiligen ECUs 106 und/oder APIs 200 speichern kann. Zum Beispiel könnte der Server 118 mit einer temporären Kennung für eine ECU 106 des Fahrzeugs 102 auf Telematikdaten des Fahrzeugs 102 zugreifen, z. B. eine Geschwindigkeit oder einen Standort des Fahrzeugs 102 anfordern. In einem anderen nicht einschränkenden Beispiel könnte der Server 118 auf ein Wi-Fi-Netzwerk des Fahrzeugs 102 mit einer temporären Kennung für eine API 200 des Fahrzeugs 102 zugreifen.
In Beispielen, in denen eine zweite ECU 106 eine Teil-ECU einer ersten ECU 106 ist, könnte eine temporäre Kennung für die zweite ECU 106 eine Verkettung einer temporären Kennung für die erste ECU 106 und einer für die zweite ECU 106 erlangten Salt-Zeichenfolge sein. Gleichermaßen könnte eine temporäre Kennung für diese ECU 106 in Beispielen, in denen eine API 200 in mehr als einer ECU 106 beinhaltet ist, z. B. einer ersten ECU 106 und einer zweiten ECU 106, eine Verkettung von temporären Kennungen für die erste und die zweite ECU 106 und der für die API 200 erlangten Salt-Zeichenfolge sein.
In einigen Beispielen kann eine Dauer einer temporären ECU-Kennung oder einer temporären Kennung der API 200 vom Detektieren eines zweiten Auslöseereignisses abhängen. Zum Beispiel könnte das zweite Auslöseereignis ein Zündung-AUS-Ereignis des Fahrzeugs 102 sein. Ein zweites Auslöseereignis könnte jedoch alternativ oder zusätzlich ein Ablauf eines festgelegten Zeitraums sein, für den die temporäre Kennung gültig ist. Die Gateway-Vorrichtung 108 könnte dazu programmiert sein, den Ablauf eines derartigen Zeitraums zu detektieren. Als Reaktion auf das Detektieren des Ablaufs einer Dauer einer temporären Kennung könnte die Gateway-Vorrichtung 108 dann eine zweite Salt-Zeichenfolge für die jeweilige ECU 106 und/oder API 200 erzeugen und dann eine neue oder zweite temporäre ECU-Kennung auf Grundlage der zweiten Salt-Zeichenfolge, z. B. durch Verketten einer statischen Kennung und der zweiten Salt-Zeichenfolge, wie vorstehend beschrieben, erzeugen. Die temporäre Kennung der ECU 106 oder API 200 kann dann durch die neue temporäre Kennung ersetzt oder aktualisiert werden.
4 ist ein Prozessablaufdiagramm, das einen beispielhaften Prozess 400 zum Erzeugen einer temporären ECU-Kennung veranschaulicht. Der Prozess 400 beginnt in einem Block 405, in dem eine Gateway-Vorrichtung 108 ein Auslöseereignis detektiert, z. B. eine eingeschaltete Zündung des Fahrzeugs 102.
Als Nächstes ruft die Gateway-Vorrichtung 108 in einem Block 410 statische Kennungen für eine oder mehrere ECUs 106 in dem Fahrzeug 102 ab. Zum Beispiel könnte die Gateway-Vorrichtung 108 die statischen Kennungen in einem Speicher, z. B. in einer Tabelle oder dergleichen, speichern und/oder könnte statische Kennungen detektieren, die als Reaktion auf das Auslöseereignis über ein Fahrzeugnetzwerk 104 kommuniziert werden.
Als Nächstes sendet die Gateway-Vorrichtung 108 in einem Block 415 eine Anforderung für eine oder mehrere Salt-Zeichenfolgen für jeweilige ECUs 106 in dem Fahrzeug 102 an einen Server 118. Wie vorstehend angemerkt, kann die Gateway-Vorrichtung 108 auch eine Kennung des Fahrzeugs 102 und die jeweiligen statischen ECU-Kennungen beim Senden der Anforderung beinhalten. In einigen Umsetzungen kann die Gateway-Vorrichtung 108 Salt-Zeichenfolgen für mehrere ECUs 106 in einer Nachricht an den Server 118 anfordern. In anderen Umsetzungen kann die Gateway-Vorrichtung 108 Salt-Zeichenfolgen für jeweilige ECUs 106 in verschiedenen jeweiligen Nachrichten an den Server 118 anfordern. Das Anfordern von Salt-Zeichenfolgen für mehrere ECUs 106 in einer einzelnen Nachricht kann Effizienz bereitstellen, z. B. kann die einzelne Nachricht weniger Bandbreite verbrauchen und/oder eine Antwort in kürzerer Zeit erhalten als mehrere Nachrichten. Andererseits können mehrere Nachrichten sicherer sein, wenn z. B. eine von mehreren Nachrichten beschädigt ist, wird nur eine und nicht alle Salt-Zeichenfolgen beschädigt.
Als Nächstes empfängt die Gateway-Vorrichtung 108 in einem Block 420 den angeforderten einen oder die angeforderten mehreren Salt-Zeichenfolgen von dem Server 118. Es ist anzumerken, dass Beispiele möglich sind, in denen der Server 118 ferner eine oder mehrere temporäre ECU-Kennungen erzeugt und die Kennungen zusätzlich zu oder anstelle der Salt-Zeichenfolgen bereitstellt. Noch ferner ist anzumerken, dass Beispiele möglich sind, in denen der Server 118 Salt-Zeichenfolgen und/oder temporäre ECU-Kennungen zur möglichen zukünftigen Verwendung durch die Gateway-Vorrichtung 108 erzeugt. Zum Beispiel könnte eine in dem Block 415 gesendete Nachricht eine Salt-Zeichenfolge und/oder eine temporäre Kennung für eine ECU 106 anfordern und könnte dann die Salt-Zeichenfolge und/oder die temporäre Kennung für einen vorbestimmten Zeitraum in einem Speicher speichern, z. B Anzahl von Stunden und könnte dann die Salt-Zeichenfolge verwenden, um eine temporäre Kennung zu erzeugen und/oder die temporäre Kennung einzusetzen, wenn der vorbestimmte Zeitraum nicht abgelaufen ist. Anders ausgedrückt könnten Salt-Zeichenfolgen und/oder temporäre Kennungen vorabgerufen werden. Salt-Zeichenfolgen, die vorabgerufen werden, könnten dann in einem Speicher, z. B. der Gateway-Vorrichtung 108, gespeichert und dann verwendet werden, um ECU-Kennungen zu erzeugen, wie in Bezug auf den Block 425 beschrieben, wenn die Gateway-Vorrichtung 108 ein zweites Auslöseereignis detektiert. Alternativ oder zusätzlich könnten temporäre Kennungen, die vorabgerufen werden, in einem Speicher einer Gateway-Vorrichtung gespeichert und dann auf Grundlage eines zweiten Auslöseereignisses eingesetzt werden, wie nachstehend in Bezug auf den Block 430 beschrieben. Zum Beispiel könnte ein erstes Auslöseereignis sein, dass das Fahrzeug den Zündung-EIN-Zustand erreicht, und ein zweites Auslöseereignis könnte eine Benutzereingabe sein, die eine ECU 106 und/oder eine API 200 erfordert, wie vorstehend beschrieben.
Als Nächstes erzeugt die Gateway-Vorrichtung 108 in einem Block 425 jeweilige temporäre ECU-Kennungen für die ECUs 106. Der Block 425 kann in Umsetzungen, in denen der Server 118 temporäre ECU-Kennungen erzeugt, weggelassen werden.
Als nächstes setzt die Gateway-Vorrichtung 108 in einem Block 430 die erzeugte eine oder die erzeugten mehreren temporären ECU-Kennungen ein. Wie vorstehend erläutert, kann die Gateway-Vorrichtung 108 die temporären ECU-Kennungen in Verbindung mit jeweiligen statischen Kennungen speichern. Ferner kann die Gateway-Vorrichtung 108 dem Server 118 temporäre ECU-Kennungen in Verbindung mit den jeweiligen statischen Kennungen der ECU 106 bereitstellen. Der Server 118 kann dann die temporären ECU-Kennungen verwenden, um auf die jeweiligen ECUs 106 zuzugreifen. Ferner kann der Block 430 in Beispielen, in denen eine neue oder zweite temporäre ECU-Kennung erzeugt werden kann, z. B. weil ein erster Zeitraum für eine temporäre Kennung abgelaufen ist, Aktualisieren einer temporären ECU-Kennung mit einer neuen oder zweiten temporären ECU-Kennung beinhalten, die zuletzt im Block 425 erzeugt wurde.
Als Nächstes können in einem Block 435 die eine oder die mehreren temporären ECU-Kennungen in dem Fahrzeugnetzwerk 104 verwendet werden. Das heißt, wenn die Gateway-Vorrichtung 108 Anforderungen von einem entfernten Server 118 empfängt, um auf eine ECU 106 des Fahrzeugs 102 zuzugreifen, kann die Gateway-Vorrichtung 108 den entfernten Server 118 gemäß der temporären ECU-Kennung authentifizieren. Ferner kann die Gateway-Vorrichtung 108 ablehnen, eine Anforderung für eine ECU 106 des Fahrzeugs 102 unter Verwendung einer statischen Kennung der ECU 106 anstelle der temporären ECU-Kennung zu authentifizieren.
In einem Block 440 kann die Gateway-Vorrichtung 108 bestimmen, ob eine Dauer für eine oder mehrere temporäre ECU-Kennungen abgelaufen ist. Wie vorstehend angemerkt, kann in einigen Beispielen die Dauer gemäß einer Zeit von einem Zündung-EIN-Ereignis des Fahrzeugs 102 bis zu einem Zündung-AUS-Ereignis des Fahrzeugs 102 definiert sein. Die Dauer könnte jedoch auch für einen Zeitraum definiert sein, z. B. eine Anzahl von Minuten oder Stunden. Falls die Dauer nicht abgelaufen ist, kann der Prozess 400 zu dem Block 435 zurückkehren. Wenn jedoch die Dauer abgelaufen ist, kann als Nächstes ein Block 445 ausgeführt werden.
In dem Block 445 kann die Gateway-Vorrichtung 108 bestimmen, ob der Prozess 400 fortzusetzen ist. Wenn zum Beispiel die Dauer aufgrund des Zündung-AUS-Ereignisses des Fahrzeugs 102 abgelaufen ist, kann der Prozess 400 im Anschluss an den Block 445 enden. Andernfalls kann der Prozess 400 zu dem Block 410 zurückkehren, um eine oder mehrere neue oder zweite Kennungen der ECU 106 zu erzeugen.
5 ist ein Prozessablaufdiagramm, das einen beispielhaften Prozess 500 zum Erzeugen einer temporären ECU-Kennung und einer temporären Kennung der API 200 veranschaulicht. Die Blöcke 505-525 sind die gleichen wie die Blöcke 405-425 des Prozesses 400 und daher werden die Blöcke 505-525 nicht separat beschrieben, um Wiederholungen zu vermeiden.
Im Anschluss an den Block 525 sendet die Gateway-Vorrichtung 108 in einem Block 530 eine Anforderung für jeweilige Salt-Zeichenfolgen für die APIs 200 in den ECUs 106 an einen Server 118, typischerweise den gleichen Server 118 wie in den Blöcken 515, 520. Die Gateway-Vorrichtung 108 kann eine Liste von statischen Kennungen für die APIs 200 speichern, wie vorstehend beschrieben. Die statischen Kennungen für die APIs 200 können zusammen mit einer Kennung des Fahrzeugs 102 in der Anforderung beinhaltet sein. In einigen Umsetzungen kann die Gateway-Vorrichtung 108 Salt-Zeichenfolgen für mehrere APIs 200 in einer Nachricht an den Server 118 anfordern und ferner Salt-Zeichenfolgen für mehrere ECUs 106 in einer derartigen Nachricht anfordern. In anderen Umsetzungen kann die Gateway-Vorrichtung 108 Salt-Zeichenfolgen für jeweilige ECUs 106 und/oder APIs 200 in verschiedenen jeweiligen Nachrichten an den Server 118 anfordern. Darüber hinaus könnten Salt-Strings und/oder temporäre Kennungen für APIs 200 vorabgerufen werden und könnten auf Grundlage eines zweiten Auslöseereignisses erzeugt und/oder eingesetzt werden, wie vorstehend in Bezug auf die ECUs 106 beschrieben.
In einem Block 535 empfängt die Gateway-Vorrichtung 108 im Anschluss an den Block 530 eine oder mehrere Salt-Zeichenfolgen für die jeweiligen APIs 200. Es ist anzumerken, dass Beispiele möglich sind, in denen der Server 118 ferner eine oder mehrere temporäre API-Kennungen erzeugt und die Kennungen zusätzlich zu oder anstelle der Salt-Zeichenfolgen bereitstellt.
In einem Block 540 erzeugt die Gateway-Vorrichtung 108 temporäre Kennungen der API 200, wie vorstehend beschrieben, d. h., Verkettungen einer Salt-Zeichenfolge mit einer temporären ECU-Kennung und/oder der statischen Kennung der API 200. Der Block 540 kann in Umsetzungen, in denen der Server 118 temporäre ECU-Kennungen erzeugt, weggelassen werden.
In einem Block 545 werden eine oder mehrere temporäre ECU-Kennungen und temporäre Kennungen der API 200 eingesetzt, z. B. wie vorstehend in Bezug auf den Block 430 beschrieben.
In dem Block 550 können die temporären ECU-Kennungen und/oder die temporären Kennungen der API 200 in dem Fahrzeug 102 zur Authentifizierung von externen Vorrichtungen, wie etwa dem Server 118, der über das Fahrzeugnetzwerk 104 Zugriff auf die ECUs 106 und/oder APIs 200 anfordert, verwendet werden, als vorstehend beschriebenen.
Die Blöcke 555, 560 sind den Blöcken 440, 445 ähnlich und werden daher nicht weiter beschrieben, um Wiederholungen zu vermeiden, außer um anzumerken, dass der Prozess 500 nach dem Block 555 zum Block 550 zurückkehrt, wenn eine Dauer für temporäre Kennungen nicht überschritten wurde, und kann andernfalls zu Block 560 übergehen. Ferner kehrt der Prozess 500 im Anschluss an den Block 560 zu dem Block 510 zurück, wenn der Prozess 500 fortgesetzt werden soll. Andernfalls kann der Prozess 500 im Anschluss an den Prozess 560 enden.
6 ist ein Prozessablaufdiagramm, das einen beispielhaften Prozess 600 für einen entfernten Server 118 zum Erzeugen von Salt-Zeichenfolgen und Verwenden von temporären Kennungen veranschaulicht. Der Prozess 600 beginnt in einem Block 605, in dem der Server 118 eine Anforderung von einer Gateway-Vorrichtung 108 in einem Fahrzeug 102 empfängt, eine oder mehrere Salt-Zeichenfolgen für die ECUs 106 und/oder APIs 200 in dem Fahrzeug 102 bereitzustellen. Die Anforderung kann eine Kennung des Fahrzeugs 102 und/oder statische Kennungen beinhalten, wie vorstehend erläutert.
In einem Block 610 im Anschluss an den Block 605 kann der Server 118 die Anforderung validieren. Zum Beispiel könnte die Gateway-Vorrichtung 108 einen Verschlüsselungsschlüssel oder dergleichen bereitstellen und der Server 118 könnte die Anforderung von der Gateway-Vorrichtung 108 unter Verwendung einer beliebigen geeigneten Authentifizierungstechnik validieren. Wenn die Anforderung nicht validiert werden kann, könnte der Prozess 600 beendet werden. Andernfalls geht der Prozess 600 zu einem Block 615 über.
Im Block 615 kann der Server 118 die angeforderte(n) Salt-Zeichenfolge(n) erzeugen. Zum Beispiel könnte die Anforderung eine angeforderte Länge einer Salt-Zeichenfolge spezifizieren und/oder der Server 118 könnte dazu programmiert sein, zum Beispiel eine Zeichenfolge mit einer bestimmten Anzahl von Bits oder Bytes zu erzeugen. Die Salt-Zeichenfolge könnte unter Verwendung einer beliebigen geeigneten Technik zum Erzeugen einer zufälligen oder pseudozufälligen Zeichenfolge erzeugt werden. Eine Salt-Zeichenfolge wird typischerweise für eine spezifische ECU 106 oder API 200 erzeugt, sodass eine Salt-Zeichenfolge nicht für temporäre Kennungen für mehrere ECUs 106 oder APIs 200 verwendet wird, wodurch eine weiter verbesserte Sicherheit bereitgestellt wird.
In einem Block 620 im Anschluss an den Block 615 sendet der Server 118 die angeforderte(n) Salt-Zeichenfolge(n) an die anfordernde Gateway-Vorrichtung 108.
In einem Block 625 empfängt der Server 118 eine oder mehrere temporäre Kennungen der ECU 106 und/oder API 200, die mit der/den in Block 620 gesendeten Salt-Zeichenfolge(n) erzeugt wurden, und speichert sie in einem Speicher.
Dann kann der Server 118 in einem Block 630 die gespeicherte(n) temporäre(n) Kennung(en) verwenden, um über die Gateway-Vorrichtung 108 auf die ECUs 106 und/oder APIs 200 in dem Fahrzeug 102 zuzugreifen. Zum Beispiel könnte der Server 118 Programmierung beinhalten, um Daten von dem Fahrzeug 102 in Bezug auf Geschwindigkeit, Standort usw. des Fahrzeugs 102 anzufordern. In einem anderen Beispiel könnte der Server 118 Programmierung beinhalten, um Anforderungen von einer Benutzervorrichtung, wie etwa einem Smartphone oder dergleichen, anzunehmen, um das Fahrzeug 102 zu steuern, z. B. Türen entriegeln, Antrieb anschalten oder abschalten usw.
Im Anschluss an den Block 630 kann der Prozess 600 enden.
Die in dieser Schrift erörterten Rechenvorrichtungen beinhalten Prozessoren und Speicher, wie vorstehend angegeben. Die Speicher beinhalten im Allgemeinen Anweisungen, die durch einen oder mehrere der Prozessoren der Rechenvorrichtungen ausführbar sind, wie vorstehend offenbarte Anweisungen, und Anweisungen zum Ausführen vorstehend beschriebener Blöcke oder Schritte von Prozessen. Computerausführbare Anweisungen können von Computerprogrammen zusammengestellt oder interpretiert werden, die unter Verwendung einer Vielfalt von Programmiersprachen und/oder -techniken erstellt wurden, darunter unter anderem, entweder allein oder in Kombination, Java™, C, C++, Visual Basic, Java Script, Python, Perl, HTML usw. Im Allgemeinen empfängt ein Prozessor (z. B. ein Mikroprozessor) Anweisungen, z. B. von einem Speicher, einem computerlesbaren Medium usw., und führt diese Anweisungen aus, wodurch das Eintreten eines oder mehrerer Prozesse veranlasst wird, einschließlich eines oder mehrerer der in dieser Schrift beschriebenen Prozesse. Derartige Anweisungen und andere Daten können unter Verwendung einer Vielfalt von computerlesbaren Medien gespeichert und übertragen werden. Eine Datei in dem Computer ist im Allgemeinen eine Sammlung von Daten, die auf einem computerlesbaren Medium gespeichert ist, wie etwa einem Speichermedium, einem Direktzugriffsspeicher usw.
Ein computerlesbares Medium beinhaltet ein beliebiges Medium, das am Bereitstellen von Daten (z. B. Anweisungen) beteiligt ist, die durch einen Computer ausgelesen werden können. Ein derartiges Medium kann viele Formen annehmen, die unter anderem nichtflüchtige Medien, flüchtige Medien usw. beinhalten. Nichtflüchtige Medien beinhalten zum Beispiel optische oder magnetische Festplatten und andere Dauerspeicher. Flüchtige Medien beinhalten einen dynamischen Direktzugriffsspeicher (dynamic random access memory - DRAM), der typischerweise einen Hauptspeicher darstellt. Gängige Formen computerlesbarer Medien beinhalten beispielsweise eine Diskette, eine Folienspeicherplatte, eine Festplatte, ein Magnetband, ein beliebiges anderes magnetisches Medium, eine CD-ROM, eine DVD, ein beliebiges anderes optisches Medium, Lochkarten, Lochstreifen, ein beliebiges anderes physisches Medium mit Lochmustern, einen RAM, einen PROM, einen EPROM, einen FLASH-EEPROM, einen beliebigen anderen Speicherchip oder eine beliebige andere Speicherkassette oder ein beliebiges anderes Medium, das von einem Computer gelesen werden kann.
Hinsichtlich der in dieser Schrift beschriebenen Medien, Prozesse, Systeme, Verfahren usw. versteht es sich, dass, obwohl die Schritte derartiger Prozesse usw. als gemäß einer gewissen geordneten Abfolge erfolgend beschrieben worden sind, die beschriebenen Schritte bei der Ausführung derartiger Prozesse in einer Reihenfolge durchgeführt werden könnten, bei der es sich nicht um die in dieser Schrift beschriebene Reihenfolge handelt. Es versteht sich zudem, dass bestimmte Schritte gleichzeitig durchgeführt, andere Schritte hinzugefügt oder bestimmte in der vorliegenden Schrift beschriebene Schritte weggelassen werden könnten. Anders ausgedrückt werden die Beschreibungen von Systemen und/oder Prozessen im vorliegenden Zusammenhang zu Zwecken der Veranschaulichung bestimmter Ausführungsformen bereitgestellt und sollten in keinster Weise dahingehend ausgelegt werden, dass sie den offenbarten Gegenstand einschränken.
Dementsprechend versteht es sich, dass die vorliegende Offenbarung, welche die vorstehende Beschreibung und die beigefügten Figuren und nachfolgenden Patentansprüche beinhaltet, veranschaulichend und nicht einschränkend sein soll. Viele Ausführungsformen und Anwendungen, die sich von den bereitgestellten Beispielen unterscheiden, werden dem Fachmann beim Lesen der vorstehenden Beschreibung ersichtlich. Der Schutzumfang der Erfindung sollte nicht unter Bezugnahme auf die vorstehende Beschreibung bestimmt werden, sondern stattdessen unter Bezugnahme auf Patentansprüche, die hier beigefügt sind und/oder in einer hierauf basierenden, nicht vorläufigen Patentanmeldung beinhaltet sind, gemeinsam mit dem vollständigen Schutzumfang von Äquivalenten, zu welchen derartige Patentansprüche berechtigen. Es wird angenommen und ist beabsichtigt, dass es zukünftige Entwicklungen im in dieser Schrift erörterten Stand der Technik geben wird und dass die offenbarten Systeme und Verfahren in derartige zukünftige Ausführungsformen einbezogen werden. Insgesamt versteht es sich, dass der offenbarte Gegenstand modifiziert und variiert werden kann.
Der ein Substantiv modifizierende Artikel „ein(e)“ sollte dahingehend verstanden werden, dass er eine(n) oder mehrere bezeichnet, es sei denn, es ist etwas anderes angegeben oder der Kontext erfordert etwas anderes. Der Ausdruck „auf Grundlage von“ schließt teilweise oder vollständig auf Grundlage von ein.

Claims

Verfahren, umfassend: als Reaktion auf ein Detektieren eines Auslöseereignisses, Abrufen einer statischen Kennung einer elektronischen Steuereinheit (ECU) über ein Fahrzeugnetzwerk; Empfangen, als Reaktion auf eine Anforderung an einen Servercomputer, einer Salt-Zeichenfolge; Erzeugen einer temporären ECU-Kennung für die ECU auf Grundlage der Salt-Zeichenfolge und der statischen Kennung; und Bereitstellen der temporären ECU-Kennung an das Fahrzeugnetzwerk.
Verfahren nach Anspruch 1, ferner umfassend: als Reaktion auf das Detektieren des Auslöseereignisses, Anfordern und Empfangen einer zweiten Salt-Zeichenfolge von dem Servercomputer oder einem zweiten Servercomputer; Erzeugen einer temporären Kennung einer Anwendungsprogrammierschnittstelle (API) für eine API, die in der ECU beinhaltet ist, auf Grundlage der temporären ECU-Kennung und der zweiten Salt-Zeichenfolge; und Bereitstellen der temporären API-Kennung an das Fahrzeugnetzwerk.
Verfahren nach Anspruch 2, wobei die API in der ECU und einer zweiten ECU beinhaltet ist.
Verfahren nach Anspruch 3, wobei die zweite ECU eine Teil-ECU der ECU ist.
Verfahren nach Anspruch 1, wobei die Anforderung an den Servercomputer die statische Kennung der ECU beinhaltet.
Verfahren nach Anspruch 5, wobei die Anforderung an den Server eine Fahrzeugkennung zusätzlich zur statischen Kennung der ECU beinhaltet.
Verfahren nach Anspruch 1, ferner umfassend Empfangen mindestens einer Salt-Zeichenfolge für mindestens eine zweite ECU als Reaktion auf die Anforderung.
Verfahren nach Anspruch 1, wobei die ECU eine von einer Vielzahl von ECUs im Fahrzeug ist, wobei das Verfahren ferner Erzeugen jeweiliger temporärer ECU-Kennungen für jeweilige ECUs in der Vielzahl von ECUs umfasst.
Verfahren nach Anspruch 1, wobei das Auslöseereignis ein Zündung-EIN-Ereignis ist.
Verfahren nach Anspruch 1, ferner umfassend: Bestimmen, dass eine Dauer der temporären ECU-Kennung abgelaufen ist; Erlangen einer zweiten Salt-Zeichenfolge; Erzeugen einer neuen temporären ECU-Kennung auf Grundlage der zweiten Salt-Zeichenfolge; und Aktualisieren der temporären ECU-Kennung mit der neuen temporären ECU-Kennung.
Verfahren nach Anspruch 1, ferner umfassend Erzeugen der temporären ECU-Kennung bei einem Detektieren eines zweiten Auslöseereignisses.
Verfahren nach Anspruch 1, ferner umfassend, in einem Servercomputer, als Reaktion auf ein Empfangen der Anforderung, Erzeugen der Salt-Zeichenfolge und Senden der Salt-Zeichenfolge an eine Computer-Gateway-Vorrichtung in einem Fahrzeug.
Verfahren nach Anspruch 12, ferner umfassend Empfangen, im Servercomputer, der temporären ECU-Kennung von der Gateway-Vorrichtung und Speichern der temporären ECU-Kennung.
Verfahren nach Anspruch 12, ferner umfassend, im Servercomputer, Beinhalten der temporären ECU-Kennung in einer Anforderung, um auf die ECU zuzugreifen.
Gateway-Computer für ein Fahrzeug, der dazu programmiert ist, das Verfahren nach einem der Ansprüche 1-9 auszuführen.