DE102017107879A1

DE102017107879A1 - Nachrichten-Authentifizierungsbibliothek

Info

Publication number: DE102017107879A1
Application number: DE102017107879.7A
Authority: DE
Inventors: Manohar Reddy NANJUNDAPPA
Original assignee: GM Global Technology Operations LLC
Current assignee: GM Global Technology Operations LLC
Priority date: 2016-04-18
Filing date: 2017-04-11
Publication date: 2017-10-19
Also published as: US20170302452A1; CN107306269A; US9923722B2

Abstract

Es wird ein Fahrzeugkommunikationsprüfsystem beschrieben, das einen Diagnosecomputer mit einem darauf gespeicherten Computerprogrammprodukt beinhaltet. Das Programmprodukt beinhaltet ein nicht-flüchtiges computerlesbares Medium den Diagnosecomputer, das ein auf dem computerlesbaren Medium gespeichertes Anwendungssoftwareprogramm beinhaltet, das Anweisungen beinhaltet, die angepasst sind, um verschlüsselte Nachrichten zu validieren, die über eine Netzwerkverbindung in einem Fahrzeug übertragen werden. Die Anweisungen beinhalten: Durchführen einer Initialisierungssequenz, die das Empfangen von Initialisierungsdaten an dem Diagnosecomputer beinhaltet, worin die Initialisierungsdaten mit einer Vielzahl von Fahrzeugsystemmodulen (VSMs) verbunden sind, die über die Fahrzeugnetzverbindung miteinander verbunden sind; Empfangen als Dateneingabe am Diagnosecomputer eine verschlüsselte Nachricht, die über die Netzwerkverbindung übertragen wird; und basierend auf den Initialisierungsdaten, Bestimmen an dem Diagnosecomputer, ob die empfangene verschlüsselte Nachricht gültig ist.

Description

TECHNISCHES GEBIET
Die vorliegende Erfindung bezieht sich auf eine Anwendungssoftware für einen Diagnosecomputer, der eine Nachrichtenauthentifizierungs-Bibliothek zum Überprüfen von über einen Fahrzeugbus übermittelten Code beinhaltet.
HINTERGRUND
Intra-Fahrzeug-Nachrichtenverkehr kann verschlüsselt werden. So kann beispielsweise ein Fahrzeug eine Anzahl von elektronischen Modulen aufweisen, die durch einen Datenbus miteinander verbunden sind, und die Module können über den Bus miteinander kommunizieren, um Fahrzeugfunktionen auszuführen. Wenn ein bösartiger Angreifer (z.B. ein Hacker) in der Lage ist, Zugang zu dem Bus zu erhalten, kann der Angreifer in der Lage sein, einige Fahrzeugfunktionen zu manipulieren oder anderweitig zu steuern, z.B. zum Nachteil eines autorisierten Benutzers. Daher besteht eine herkömmliche Praxis darin, den über den Bus gesendeten Nachrichtenverkehr (zwischen den Modulen) zu verschlüsseln. Wenn also der Angreifer einen unberechtigten Zugriff erlangt, wird der Angreifer nur verschlüsselte Nachrichten entdecken, was es wahrscheinlich macht, dass der Angreifer das Fahrzeug manipulieren oder steuern kann.
Während des Entwurfs und der Entwicklung müssen derartige Fahrzeugdatenbussysteme getestet werden, um zu validieren und zu überprüfen, ob das System ordnungsgemäß arbeitet, z.B. bevor das Fahrzeug an einen Kunden (oder autorisierten Benutzer) verkauft wird. Fahrzeughersteller können die Subsystem-Entwicklung an Lieferanten weitergeben. So kann zum Beispiel der Hersteller einen Lieferanten anfordern, die Bus- und Modulschnittstelle bereitzustellen (z.B. wo die Schnittstellen den Modulen erlauben, miteinander zu kommunizieren). Bei der Lieferantenentwicklung muss der Lieferant oft das Datenbussystem testen und validieren. Der Hersteller kann jedoch wünschen, dem Lieferanten keine Sicherheitsdaten zur Verfügung zu stellen, z.B. kann der Hersteller es wünschen, dem Lieferanten keinen Verschlüsselungsschlüssel zur Entschlüsselung des internen Nachrichtenverkehrs zur Verfügung zu stellen. So wird ein Mechanismus oder ein Werkzeug benötigt, das dem Lieferanten zur Verfügung gestellt werden kann, mit dem der Lieferant den Betrieb des Fahrzeugdatenbussystems validieren kann, ohne dem Lieferanten die gewissen Sicherheitsdaten zur Verfügung zu stellen.
ZUSAMMENFASSUNG
Gemäß einer Ausführungsform der Erfindung wird ein Computerprogrammprodukt bereitgestellt, das ein nichtflüchtiges computerlesbares Medium für einen Diagnosecomputer beinhaltet, das ein auf dem computerlesbaren Medium gespeichertes Anwendungssoftwareprogramm beinhaltet, das Anweisungen beinhaltet, die angepasst sind, um verschlüsselte Nachrichten zu validieren, die über eine Fahrzeugnetzwerkverbindung übertragen werden. Die Anweisungen beinhalten: Durchführen einer Initialisierungssequenz, die das Empfangen von Initialisierungsdaten an dem Diagnosecomputer beinhaltet, worin die Initialisierungsdaten mit einer Vielzahl von Fahrzeugsystemmodulen (VSMs) verbunden sind, die über die Fahrzeugnetzverbindung miteinander verbunden sind; Empfangen als Dateneingabe am Diagnosecomputer eine verschlüsselte Nachricht, die über die Netzwerkverbindung übertragen wird; und basierend auf den Initialisierungsdaten, Bestimmen an dem Diagnosecomputer, ob die empfangene verschlüsselte Nachricht gültig ist.
Gemäß einer weiteren Ausführungsform der Erfindung wird ein Verfahren zur Validierung einer verschlüsselten Nachricht an einen Diagnosecomputer bereitgestellt, die über eine Fahrzeugnetzwerkverbindung übertragen wird. Das Verfahren beinhaltet: Empfangen von Initialisierungsdaten an dem Diagnosecomputer, worin die Initialisierungsdaten von einer Vielzahl von Fahrzeugsystemmodulen (VSMs) empfangen werden, die über die Fahrzeugnetzverbindung miteinander verbunden sind; Empfangen einer verschlüsselten Nachricht an dem Diagnosecomputer, worin die verschlüsselte Nachricht von einer der Vielzahl von VSMs über die Netzwerkverbindung übertragen wurde; basierend auf den Initialisierungsdaten, Bestimmen an dem Diagnosecomputer, ob die empfangene verschlüsselte Nachricht gültig ist; und Bereitstellen von Ausgangsdaten an dem Diagnosecomputer, die anzeigen, ob die empfangene verschlüsselte Nachricht gültig oder ungültig war.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Eine oder mehrere Ausführungsformen der Erfindung werden im Folgenden in Verbindung mit den beigefügten Zeichnungen beschrieben, worin gleiche Bezeichnungen gleiche Elemente bezeichnen, und worin:
1 ein Blockdiagramm ist, das eine Ausführungsform eines Fahrzeugkommunikationstestsystems darstellt, das in der Lage ist, das hierin offenbarte Verfahren zu verwenden;
2 ein schematisches Diagramm eines Teils des dargestellten Systems von 1 ist; und
3 ein Flussdiagramm ist, das ein Verfahren zur Verwendung des veranschaulichten Kommunikationssystems der 1–2 darstellt.
AUSFÜHRLICHE BESCHREIBUNG DER VERANSCHAULICHTEN
AUSFÜHRUNGSFORM(EN)
Mit Bezug auf 1 ist eine Betriebsumgebung gezeigt, die ein Fahrzeugkommunikationstestsystem 10 umfasst, das verwendet werden kann, um das hierin offenbarte Verfahren zu implementieren. Das Testsystem 10 beinhaltet ein Fahrzeug 12 mit einem Kommunikationssystem 14 darin, einen ersten Diagnosecomputer 16 zum Analysieren des mit dem Kommunikationssystem 14 verbundenen Nachrichtenverkehrs und einen zweiten Diagnosecomputer 20 zum Bestimmen der Nachrichtenverkehrsverschlüsselung. Zusammen können die ersten und zweiten Computer 16, 20 von einem Fahrzeugsubsystemlieferanten verwendet werden, um den Betrieb des Systems 14 zu validieren; und insbesondere kann der Computer 20 die Validierung der Kommunikationssystemsicherheit beim Lieferanten erleichtern, ohne dem Anbieter bestimmte Sicherheitsdaten (z.B. Verschlüsselungsinformationen, wie beispielsweise einen oder mehrere Schlüssel) zu liefern. Es versteht sich, dass das offenbarte Verfahren mit einer beliebigen Anzahl von unterschiedlichen Systemen verwendet werden kann und nicht speziell auf die hier gezeigte Betriebsumgebung einschränkt ist.
Fahrzeug 12 ist in der veranschaulichten Ausführungsform als ein Personenkraftwagen dargestellt, es sollte jedoch beachtet werden, dass jedes andere Fahrzeug, einschließlich Motorräder, Lastwagen, Geländewagen (SUV), Campingfahrzeuge (RV), Wasserfahrzeuge, Flugzeuge usw. ebenfalls verwendet werden kann. Das nachstehend beschriebene Testsystem 10 kann durchgeführt werden, wenn das Fahrzeug 12 (oder Komponenten davon) in einer Fahrzeugfertigungseinrichtung (z.B. vor dem Verkauf) an einer autorisierten Fahrzeug-Servicezentrale (z.B. nach dem Verkauf des Fahrzeugs) oder einer anderen geeigneten Stelle.
Das Kommunikationssystem 14 im Fahrzeug 12 beinhaltet eine Netzwerkverbindung 22, die mehrere Fahrzeugsystemmodule (VSMs) 24 miteinander verbindet. Die Netzwerkverbindung 22 ist als Kommunikationsbus dargestellt; dies ist aber nur ein Beispiel. Nicht beschränkende Beispiele geeigneter kabelgebundener Netzwerkverbindungen beinhalten ein Controller Area Network (CAN), einen medienorientierten Systemtransfer (MOST), ein lokales Kopplungsstrukturnetzwerk (LIN), ein lokales Netzwerk (LAN) und andere geeignete Verbindungen, wie z.B. Ethernet oder andere, die den bekannten ISO-, SAE- und IEEE-Standards und Spezifikationen entsprechen, um nur einige zu nennen. Es sollte erkannt werden, dass andere Arten von Netzwerkverbindungen 22 zusätzlich zu anderen drahtgebundenen und/oder drahtlosen Netzwerken in Betracht gezogen werden. So kann beispielsweise in einer Ausführungsform die VSMs 24 Teil eines drahtlosen lokalen (oder Fahrzeug-)Bereichsnetzwerks (z.B. eines WLAN oder WVAN) sein, das – z.B. nach irgendeinem geeigneten Kurzstrecken-Drahtloskommunikations-Protokoll (SRWC) arbeitet. Nicht einschränkende SRWC-Implementierungen beinhalten Wi-Fi, Wi-Fi Direct, Bluetooth jedes geeigneten Protokolls, um nur einige Beispiele.
Die VSMs 24 können in Form von elektronischen Hardwarekomponenten vorliegen, die sich im gesamten Fahrzeug 12 befinden und typischerweise eine Eingabe von einem oder mehreren Sensoren (nicht gezeigt) empfangen und die erfasste Eingabe verwenden, um eine Diagnose, Überwachung, Steuerung, Berichterstattung und/oder andere Funktionen auszuführen. Jeder der VSMs 24 ist vorzugsweise durch einen Kommunikationsbus (z.B. Verbindung 22) miteinander verbunden. Nicht beschränkende Beispiele von VSMs 24 beinhalten eine Fahrzeugtelematikeinheit, ein GPS-Modul, ein Motorsteuerungsmodul (ECM), ein Antriebsstrangsteuermodul (PCM) ein Bordnetzsteuergerät (BSG) und dergleichen. So kann beispielsweise die Telematikeinheit unter anderem die Kommunikation mit Geräten außerhalb des Fahrzeugs – z.B. über zellulare Kommunikation sowie eine drahtlose Drahtloskommunikation (Wi-Fi, Bluetooth usw.) ermöglichen. Ein GPS-Modul kann GPS-Satellitendaten empfangen und zur Erzeugung von Kartendaten sowie zur Turn-by-Turn-Navigation verwendet werden, um nur einige Beispiele zu nennen. Ein ECM kann verschiedene Aspekte des Motorbetriebs wie beispielsweise Brennstoffzündung und Zündzeitpunkt steuern. Und zum Beispiel kann ein PCM den Betrieb einer oder mehrerer Komponenten des Fahrzeug-Antriebsstrangs regulieren, während ein BCM verschiedene elektrische Komponenten, die sich im gesamten Fahrzeug 12 befinden, wie die Krafttürschlösser und Scheinwerfer des Fahrzeugs steuern. Diese sind natürlich nur Beispiele für VSMs 24; andere Implementierungen können anstelle von und/oder zusätzlich zu den vorstehend erläuterten verwendet werden. Obwohl nicht einschränkend sein zu wollen, können Fahrzeuge, wie das Fahrzeug 12, Dutzende von VSMs 24 aufweisen (z.B. in einer Ausführungsform 30–40 VSMs).
Wie in 1 gezeigt, kann jeder VSM 24 kann eine elektronische Steuereinheit (ECU) 26 beinhalten, die einen oder mehrere Prozessoren 28 beinhaltet, die mit Speichervorrichtungen oder Speicher 30 und einer Sicherheitsperipherie oder einer speziellen kryptographischen Vorrichtung 32 gekoppelt sind. Der Prozessor 28 kann jede Geräteart sein, die elektronische Befehle verarbeiten kann, einschließlich Mikroprozessoren, Mikrocontrollern, Hostprozessoren, Steuerungen, Fahrzeugkommunikationsprozessoren und anwendungsspezifische integrierte Schaltungen (ASICs). Es kann ein dedizierter Prozessor sein, der nur für die jeweilige VSM 24 verwendet wird oder mit anderen Fahrzeugsystemen geteilt werden kann. Der Prozessor 28 führt verschiedene Arten von digital gespeicherten Anweisungen aus, wie beispielsweise Software oder Firmwareprogramme 34, die im Speicher 30 (oder am Prozessor 28) gespeichert sind und die es dem VSM 24 ermöglichen, beliebige geeigneten Dienste bereitzustellen. So kann zum Beispiel der Prozessor 28 Programme oder Prozessdaten ausführen, um zumindest einen Teil des hier diskutierten Verfahrens auszuführen, wie nachfolgend erörtert wird.
Exemplarische nichtflüchtige computernutzbare Speichervorrichtungen 30 beinhalten ein herkömmliches Computersystem-RAM (random access memory), ROM (read only memory), EPROM (löschbarer, programmierbarer ROM), EEPROM (elektrisch löschbarer, programmierbarer ROM) und magnetische oder optische Platten oder Bänder. Es versteht sich daher, dass die Verfahren zumindest teilweise von beliebigen elektronischen Geräten wie beispielsweise Prozessorschaltungen oder Vorrichtungen (z.B. Prozessor 28) durchgeführt werden können, die in der Lage sind, zumindest einige vorbestimmte Anweisungen auszuführen.
Das Sicherheits-Peripheriegerät 32 kann jedes elektronische Gerät sein, das Nachrichteninhaltsdaten empfängt und entweder die Nachrichteninhaltsdaten verschlüsselt oder entschlüsselt, wodurch es dem momentanen VSM 24 oder einem anderen VSM 24 innerhalb des Fahrzeugs 12 zur Verfügung stellt. Wenn beispielsweise das VSM 24 eine Nachricht über die Netzwerkverbindung 22 empfängt, kann das Sicherheitsperipheriegerät 32 die empfangene Nachricht entschlüsseln und validieren. Wenn die Nachricht als nicht gültig bestimmt wird, kann die Peripherie 32 eine Angabe eines Fehlers oder einer möglichen Sicherheitsverletzung (z.B. einer anderen VSM 24 oder sogar eines entfernten Servers) bereitstellen. Und zum Beispiel, bevor das VSM eine Nachricht über die Verbindung 22 sendet, kann das Sicherheitsperipheriegerät 32 die Nachricht verschlüsseln.
In mindestens einer Ausführungsform ist das Sicherheits-Peripheriegerät 32 physisch und logisch von dem Rest der ECU 26 (und von anderen VSM-Komponenten) partitioniert. So kann beispielsweise das Peripheriegerät 32 separate Hardware, separate Software oder Firmware oder beide umfassen. In einer Ausführungsform umfasst das Sicherheitsperipheriegerät 32 einen dedizierten Prozessor 32p, einen dedizierten Speicher 32m, dedizierte Anweisungen und dergleichen; dies ist jedoch nicht erforderlich. Somit können in einer Ausführungsform nur die Peripheriegeräte 32 jeder ECU 26 die Fähigkeit haben, den über die Netzwerkverbindung 22 gesendeten Nachrichtenverkehr zu verschlüsseln und zu entschlüsseln. Somit sollte erkannt werden, dass jede Partitionierung des Sicherheitsperipheriegeräts 32 von dem Rest der ECU 26 und/oder der Netzwerkverbindung 22 angepasst werden kann, um zu verhindern, dass böswillige Angreifer die geheimen Schlüsselinformationen erwerben und böswillig verwenden – um z.B. eine unbefugte Benutzung des Fahrzeugs 12 oder der Fahrzeugsystemmodule 24 zu verhindern. So würde zum Beispiel der Angreifer, auch wenn ein bösartiger Angreifer die Verbindung 22 und/oder eine oder mehrere der ECUs 26 verletzt, die Sicherheitsperipherie(n) 32 verletzen müssen, um eine Nachricht oder eine Spoof-Nachricht zu interpretieren. Die physische und/oder logische Partitionierung hemmt die Erfolgswahrscheinlichkeit des Angreifers.

Jede Sicherheitsperipherie 32 in dem Fahrzeug 12 kann einen oder mehrere Tasten oder Geheimnisse in einer Nachschlagtabelle speichern (z.B. im Speicher 32m). Die Schlüssel können jede geeignete Art von Verschlüsselungsschlüssel oder Code sein; jedoch sind in mindestens einer Ausführungsform die Tasten symmetrische oder gemeinsam genutzte Schlüssel. Weiterhin sind in mindestens einer Ausführungsform die Tasten nur den Sicherheits-Peripheriegeräten 32 bekannt. Die nachstehende Tabelle I ist ein nicht einschränkendes Beispiel für eine Nachschlagetabelle (deren Inhalt im Speicher 32m gespeichert werden kann). Während ferner zehn verschiedene Tasten dargestellt sind (Key1–Key10), sollte man verstehen, dass andere Ausführungsformen mehr oder weniger Tasten aufweisen können. Tabelle I.

Zähler-ID	Gemeinsamer Schlüssel	Zähler-ID	Gemeinsamer Schlüssel	Zähler-ID	Gemeinsa mer Schlüssel
1	Schlüssel1	11	Schlüssel1	21	Schlüssel1
2	Schlüssel2	12	Schlüssel2	22	Schlüssel2
3	Schlüssel3	13	Schlüssel3	23	Schlüssel3
4	Schlüssel4	14	Schlüssel4	24	Schlüssel4
5	Schlüssel5	15	Schlüssel5	25	Schlüssel5
6	Schlüssel6	16	Schlüssel6	...	...
7	Schlüssel7	17	Schlüssel7
8	Schlüssel8	18	Schlüssel8
9	Schlüssel9	19	Schlüssel9
10	Schlüssel10	20	Schlüssel10

In mindestens einer Ausführungsform umfasst jedes Sicherheits-Peripheriegerät 32 einen Zähler, um einen Zähler-Identifikator (ID) oder einen Zähl-ID-Wert zu erzeugen, der den Tasten zugeordnet ist. Der Zähler kann in Software konfiguriert werden. Hardware-Implementierungen sind aber auch möglich. Der Zähler kann in geeigneter Weise inkrementiert werden; bei mindestens einer Ausführungsform wird jedoch der Zähler jedes Mal inkrementiert, wenn eine Nachricht gesendet wird, die durch das spezielle Sicherheitsperipheriegerät 32 verschlüsselt wird. Und basierend auf dem erzeugten Zähler-ID-Wert kann das Sicherheits-Peripheriegerät 32 bestimmen, welcher Schlüssel zum Verschlüsseln der gesendeten Nachricht verwendet werden soll. Nicht beschränkende Beispiele für Zähler-ID-Werte sind ebenfalls in Tabelle I gezeigt; wieder sollen diese nur die Nachschlagetabelle veranschaulichen.
Tabelle I veranschaulicht, dass jeder Schlüssel mit einem oder mehreren Zähler-ID-Werten assoziiert sein kann. Bei dieser Implementierung sind die Zähler-ID-Werte 1, 11, 21 usw. (z.B. n + 10) Schlüssel1 zugeordnet. Ähnlich sind die Zähler-ID-Werte 2, 12, 22 usw. (z. B. wieder, n + 10) mit Schlüssel2 verbunden usw. Dies ist lediglich ein Beispiel, um zu veranschaulichen, dass ein einziger Schlüssel mehreren Zähler-ID-Werten zugeordnet sein kann. Andere Implementierungen sind ebenfalls möglich.
Beim Übertragen einer Nachricht von einer Sender-ECU 26 zu einer Ziel-ECU 26 kann ein entsprechendes Absendersicherheits-Peripheriegerät 32 einen Nachrichteninhalt (z.B. von seinem entsprechenden VSM 24 und/oder über die ECU 26) empfangen. In einer Ausführungsform kann das Senderperipheriegerät 32 einen Nachrichtenauthentifizierungscode (MAC) durch Signieren des Nachrichteninhalts mit einer der Tasten in der Nachschlagtabelle (z.B. gemäß dem Zähler-ID-Wert des Peripheriegeräts) erzeugen. Die Verwendung eines MAC ist ebenfalls exemplarisch; z.B. können stattdessen andere Formen der Verschlüsselung verwendet werden. Verschlüsselungssignaturen – einschließlich MACs – sind allgemein bekannt und werden hierin nicht weiter beschrieben. Danach kann das Peripheriegerät 32 den Zähler inkrementieren (natürlich kann bei anderen Ausführungsformen der Zähler vor dem Erfassen eines Schlüssels aus der Nachschlagtabelle inkrementiert werden).
Um die Nachricht zu übertragen, kann das Peripheriegerät 32 einen Nachrichtenkörper und einen Header vorbereiten. In mindestens einer Ausführungsform beinhaltet der Körper der Nachricht unverschlüsselten Nachrichteninhalt und den MAC (z.B. verschlüsselten Nachrichteninhalt) und der Header beinhaltet einen unverschlüsselten Zähler-ID-Wert, der mit dem Schlüssel verbunden ist, der zum Verschlüsseln der Nachricht verwendet wird. In einigen Implementierungen kann der Kopf- und/oder Nachrichtentext andere Daten beinhalten; z.B. eine Kennung der ECU, einen Prioritätswert usw. Sobald die Nachricht von der Peripherie 32 vorbereitet ist, kann die Sender-ECU 26 sie davon empfangen und über die Netzwerkverbindung 22 übertragen.
Wenn die Ziel-ECU 26 die Nachricht empfängt, kann die Nachricht zuerst durch ihr jeweiliges Sicherheits-Peripheriegerät 32 (z.B. ein Ziel-Sicherheits-Peripheriegerät) authentifiziert werden. Nachrichten, die nicht authentifiziert werden können, können ignoriert werden (z.B. und können zu Fehlermeldungen innerhalb des Kommunikationssystems 14 oder zu einem entfernten Server, einem Fahrzeug-Backend-System oder dergleichen führen). Somit kann nach dem Empfang das Ziel-Peripheriegerät 32 den Zähler-ID-Wert aus dem Header extrahieren. Unter Verwendung des extrahierten Wertes kann das Peripheriegerät 32 unter Verwendung seiner eigenen Nachschlagtabelle bestimmen, welche Taste verwendet wird, um die Nachricht zu entschlüsseln. So kann beispielsweise die Nachschlagetabelle in dem Zielperipheriegerät 32 die gleiche wie die Nachschlagtabelle in der Senderperipherie 32 sein.
Unter Verwendung der entsprechenden Taste kann das Zielperipheriegerät 32 den MAC entschlüsseln. Der entschlüsselte MAC kann entschlüsselte Nachrichteninhaltsdaten liefern. Das Zielperipheriegerät 32 kann dann diese entschlüsselten Inhaltsdaten mit den unverschlüsselten Inhaltsdaten vergleichen, die in dem Körper der Nachricht empfangen werden. Wenn der entschlüsselte Nachrichteninhalt derselbe ist wie der unverschlüsselte Nachrichteninhalt, dann authentifiziert oder validiert das Zielsicherheits-Peripheriegerät 32 die Nachricht. Wenn jedoch der entschlüsselte Nachrichteninhalt nicht identisch mit dem unverschlüsselten Nachrichteninhalt ist, wird die Nachricht ignoriert und gilt als ungültig.
Wie in 1 gezeigt, beinhaltet die Netzwerkverbindung 22 in mindestens einer Ausführungsform einen Diagnoseanschluss 40 – z.B. für den Diagnose- und/oder anderen Zugriff auf das Kommunikationssystem 14. Der Port 40 kann sich direkt mit der Netzwerkverbindung 22 verbinden oder in einigen Implementierungen kann der Port 40 auf einem VSM 24 oder einer ECU 26 angeordnet sein – z.B. indirekt mit der Verbindung 22 verbunden sein. So können beispielsweise in mindestens einer Ausführungsform der Diagnoseanschluss 40 angepasst sein, um eine Verbindung zu einem Test-VSM oder einem Diagnosetestwerkzeug, wie dem ersten Diagnosecomputer 16, herzustellen. Die Implementierung von Diagnosehäfen ist allgemein bekannt; Fachleute werden verschiedene Aspekte ihrer Verwendung zu schätzen wissen.
Wenn man sich nun dem ersten Diagnosecomputer 16 zuwendet, kann der Computer 16 ein beliebiger kommerzieller Datenprotokollierungscomputer oder irgendeine Vorrichtung sein, die die Kommunikation mit der Verbindung 22 ermöglicht. In einer Ausführungsform ist der Computer 16 lediglich eine Schnittstelle zwischen der Kommunikationsnetzwerkverbindung 22 und dem zweiten Diagnosecomputer 20. In einer anderen Ausführungsform kann der Computer 16 den Monitor-Datenbusverkehr durch Empfangen eines oder mehrerer serieller Eingaben angepasst werden; und es kann angepasst werden, um Datenbusverkehr mit einem oder mehreren seriellen Ausgängen zu testen oder zu simulieren – z.B. mit dem Anschluss 40 über ein Kabel oder Kabelbaum 42 verbunden. So kann beispielsweise unter Verwendung des Computers 16 der Nachrichtenverkehr auf der Verbindung 22 empfangen, überwacht, analysiert, simuliert, kalibriert und dergleichen sein. Zusätzlich kann der Computer 16 auch Testnachrichten auf die Verbindung 22 übertragen. Bei mindestens einer Implementierung wird der erste Diagnosecomputer 16 von einem Verkäufer oder Lieferanten an einen Fahrzeughersteller verwendet und der Computer 16 ist nicht in der Lage, verschlüsselten Nachrichtenverkehr zu entschlüsseln – weil die Nachrichtenschlüssel nur den Sicherheitsperipherien 32 der jeweiligen ECUs 26 auf der Verbindung 22 bekannt sind. Nicht beschränkende kommerzielle Beispiele des ersten Computers 16 beinhalten Datenlogger, wie beispielsweise CANoe von Vector Informatik GmbH und Vehicle Spy von Intrepid Control Systems, Inc., um nur ein Paar zu nennen.
Der erste Computer 16 ist mit dem zweiten Diagnosecomputer 20 über ein weiteres Kabel oder Kabelbaum 44 gekoppelt dargestellt. Der zweite Diagnosecomputer 20 kann jede geeignete Rechenvorrichtung mit einem oder mehreren Prozessoren 46 und dem Speicher 48 sein. Der Prozessor 46 und der Speicher 48 können beliebige geeignete Hardwaremerkmale oder Parameter aufweisen – z.B. ähnlich wie vorstehend beschrieben (in Bezug auf den Prozessor 28, Speicher 30), mit der Ausnahme, dass jede Komponente 46, 48 Teil des Computers 20 ist (z.B. anstatt VSM 24). So kann beispielsweise der Computer 20 angepasst sein, um Betriebssystemanweisungen und jede geeignete Softwareanwendung 50 auszuführen, die in dem Speicher 48 gespeichert ist. In mindestens einer Ausführungsform ist der zweite Computer 20 ein Laptop- oder Desktop-Computergerät, das von autorisierten Fahrzeugherstellern und/oder Ingenieuren bei der Entwicklung des Fahrzeugkommunikationssystems 14 verwendet wird; dies ist jedoch nur ein nicht einschränkendes Beispiel. Somit kann der Computer 20 in einigen Implementierungen über ein privates oder öffentliches Netzwerk wie das Internet zugänglich sein. Auf diese Weise kann der Computer 20 Testdaten oder Testergebnisse an ein Fahrzeug-Backend-System oder -Server übermitteln, das Fahrzeugdaten, die mehreren Fahrzeugen zugeordnet sind, speichert und analysiert.
Zumindest eine im Speicher 48 gespeicherte Softwareanwendung 50 beinhaltet eine Nachrichtenauthentifizierungs-Bibliothek. Die Bibliothek kann ein Satz von Befehlen sein, die angepasst sind, um verschlüsselte Nachrichten als Eingabe (z.B. unter Verwendung des Computers 20) zu empfangen, die Nachrichten zu entschlüsseln und dadurch zu versuchen, zu bestätigen, dass die Nachrichten, die über die Verbindung 22 durch die VSMs 24 gesendet werden, unbeschädigt oder anderweitig gültig sind. Die Softwareanwendung 50 kann an Anbieter oder Lieferanten zur Verfügung gestellt werden, um diese Lieferanten bei der Entwicklung und dem Testen des Kommunikationssystems 14 zu unterstützen. Es versteht sich, dass mit der Anwendung 50 die Lieferanten bestimmen können, ob eine gesendete oder empfangene Nachricht auf der Verbindung 22 VALID oder INVALID ist (z.B. Pass oder Fail). Gemäß einer Ausführungsform kann die Anwendungsbibliothek 50 dem Anbieter jedoch keinen Zugriff auf die tatsächlichen Verschlüsselungsschlüssel gewähren, die verwendet werden, um die Gültigkeit zu bestimmen.
Unter Bezugnahme nun auf 2, beinhaltet die Abbildung eine schematische Darstellung einiger der Komponenten des Kommunikationstestsystems 10 (1). Insbesondere ist die Anwendungsbibliothek 50 schematisch mit Testanweisungen 60, einem oder mehreren kryptographischen Algorithmen 62 und einer Kalibriertabelle 64 dargestellt, von denen jede in einer Speichervorrichtung 48 des Computers 20 gespeichert sein kann. Die Anweisungen 60 können so angepasst werden, dass sie ähnlich zu den Anweisungen arbeiten, die in jedem der Sicherheitsperipheriegeräte 32 (z.B. in jeder ECU 26) gespeichert und ausgeführt werden. Wie nachfolgend noch näher erläutert wird, kann eine über die Netzwerkverbindung 22 gesendete Nachricht an der Ziel-ECU 26 sowie an dem zweiten Rechner (unter Verwendung von Anweisungen 60) entschlüsselt werden. Ähnlich könnte die Bibliothek 50 unter Verwendung der Anweisungen 60 eine Nachricht auf die Verbindung 22 übertragen, die auf eine der VSMs 24 – z.B. B. die Verschlüsselung der Nachricht vor der Übertragung; wieder wird dies im Folgenden näher erläutert.
Die kryptographischen Algorithmen 62 können jede geeignete Anzahl von Algorithmen beinhalten, die in der Technik bekannt sind oder nachfolgend in Betracht gezogen werden. Auf diese Weise kann die Anwendungsbibliothek 50 mit Kommunikationssystemen 14 für verschiedene Fahrzeuge verwendet werden – z.B. worin ein Fahrzeug mit einem oder mehreren Algorithmen und wobei ein Fahrzeug einen oder mehrere Algorithmen verwendet und wo ein anderes Fahrzeug mindestens einen anderen Algorithmus verwendet. Somit können der zweite Computer 20 und die Bibliothek 50 über verschiedene Fahrzeugplattformen betrieben werden.
Die Kalibriertabelle 64 kann eine Nachschlagetabelleninformation von jedem der Sicherheitsperipheriegeräte 32 in dem Fahrzeug 12 beinhalten. So kann beispielsweise Tabelle 64 die Schlüssel beinhalten, die von jedem der Peripheriegeräte 32 in dem Fahrzeug 12 verwendet werden sowie die aktuellen Zähler-IDs jedes der Peripheriegeräte 32. Wie nachfolgend noch erläutert wird, kann, wenn der Diagnosecomputer 20 mit der Verbindung 22 (z.B. über den Computer 16) verbunden ist, eine Initialisierungs- oder Kalibrierungssequenz auftreten, in der die Anwendungsbibliothek 50 Zähldaten von jedem Sicherheitsperipheriegerät 32 herunterlädt oder empfängt. Die Initialisierungssequenz kann auch die Bibliothek 50 beinhalten, die auch andere Daten empfängt: z.B. eine Angabe des in dem bestimmten Fahrzeug 12 verwendeten kryptographischen Algorithmus und/oder eine Angabe, welche Schlüssel in Bezug auf die Zähler-IDs verwendet werden. Diese Anzeigen können von der Bibliothek 50 mit einem oder mehreren Identifikatoren oder Identifizierungscodes empfangen werden. So könnte beispielsweise ein einzelner Code verwendet werden, um die Bibliothek 50 zu identifizieren, welche Algorithmen (s) in dem Fahrzeug 12 verwendet werden und welche Schlüsselsätze.
Es sollte erkannt werden, dass die Bibliothek 50 auch Kalibriertabellendaten beinhalten könnte, die einer Anzahl von verschiedenen Plattformen zugeordnet sind. So könnte beispielsweise die Bibliothek mehrere Sätze von Schlüsseln oder dergleichen umfassen. Wie nachfolgend beschrieben wird, kann unter Verwendung der Testanweisungen 60, der kryptographischen Algorithmen 62 und der Kalibriertabelle 64 die Anwendungsbibliothek 50 versuchen, verschlüsselte Nachrichten zu validieren, die über die Verbindung 22 zwischen den VSMs 24 übertragen werden, und darüber, ob diese verschlüsselten Nachrichten gültig waren oder ungültig.
Somit beinhalten nicht-beschränkende Beispiele der Anwendungsbibliothek 50 ein Softwareprogramm(e) oder ein Computerprogrammprodukt, das aus Programmanweisungen in Quellcode, Objektcode, ausführbaren Code oder anderen Formaten besteht; Firmware-Programm(e); Hardwarebeschreibungssprache (HDL) Dateien; oder dergleichen. Jeder der vorstehenden kann auf einem computerverwendbaren oder lesbaren Medium ausgeführt sein, das eine oder mehrere Speichervorrichtungen oder Artikel (z.B. Speicher 48) beinhaltet. Ferner kann in mindestens einer Ausführungsform zumindest ein Teil der Anwendungsbibliothek 50 auf einer dedizierten Hardware gespeichert sein, die auf dem Computer 20 installiert sein kann; z.B. partitioniert von anderen Prozessoren und anderer Computersystem-Hardware des Computers 20 – z.B. aus den gleichen oder ähnlichen Gründen, wie vorstehend erläutert.
2 veranschaulicht auch den ersten Computer 16, der den Nachrichtenverkehr 70 an den zweiten Computer 20 weiterleitet. So kann beispielsweise der Computer 20 – der über den Port 40 mit der Netzwerkverbindung 22 gekoppelt ist – verschlüsselte Nachrichten an den zweiten Computer 20 weiterleiten. Eine oder mehrere Verfahren zur Verwendung der Anwendungsbibliothek 50 werden nachfolgend näher beschrieben.
Verfahren –
3 veranschaulicht ein Verfahren 300 zum Bestimmen, ob eine in einem Fahrzeugkommunikationssystem 14 übertragene Nachricht gültig ist. Der Anfangs- oder Vorstufenschritt 305 beinhaltet die Schritte 310, 315 und 320. In Schritt 310 kann der erste Computer 16 über den Anschluss 40 mit dem Fahrzeuganschluss 22 verbunden sein und der zweite Computer 20 kann mit dem Computer 16 verbunden sein. So kann beispielsweise ein Ende des Kabelbaums 42 mit dem Anschluss 40 gekoppelt sein, und ein gegenüberliegendes Ende des Kabelbaums 42 kann mit dem ersten Computer 16 (z.B. unter Verwendung von Verbindern) verbunden sein. In ähnlicher Weise kann ein Ende des Kabelbaums 44 mit dem ersten Computer 16 gekoppelt sein, und ein gegenüberliegendes Ende des Kabelbaums 44 kann mit dem zweiten Computer 20 (z.B. auch unter Verwendung von Verbindern) gekoppelt sein. Schließlich kann die Anwendungsbibliothek 50 im Computer 20 mit der Netzwerkverbindung 22 gekoppelt sein. Das ist nur ein Beispiel; andere verdrahtete oder drahtlose Implementierungen werden auch in Betracht gezogen.
In Schritt 315 kann ein VSM-zu-VSM-Nachrichtenverkehr auftreten. Dieser Schritt kann vor, nach und/oder während des Schrittes 310 auftreten. So können beispielsweise Nachrichten 70 über die Verbindung 22 von einem VSM 24 zu einem anderen übertragen werden. Zumindest ein Teil des Nachrichtenverkehrs kann unter Verwendung des Sicherheitsperipheriegeräts 32 des jeweiligen Senders VSM 24, wie vorstehend beschrieben, verschlüsselt werden. In einer Ausführungsform beinhalten verschlüsselte Nachrichten einen Header, der mindestens den Zähler-ID-Wert des Senderperipheriegeräts 32 und eine Nutzlast trägt, die mindestens unverschlüsselten Nachrichteninhalt und einen MAC (der eine verschlüsselte Version des Nachrichteninhalts beinhaltet) trägt. Es wird in Betracht gezogen, dass in mindestens einer Ausführungsform von Schritt 315 das Verfahren 300 während des Engineering-Tests und der Entwicklung auftritt. In einigen Implementierungen kann dies bei einem Lieferanten auftreten, der Hardware bereitstellt, die mit dem Kommunikationssystem 14 verbunden ist.
In dem nachfolgenden Schritt 320 kann der zweite Computer 20 eine Initialisierungs- oder Kalibrierungssequenz ausführen. Die Initialisierungssequenz beinhaltet das Empfangen von Zähler-ID-Werten von jeder der jeweiligen ECUs 26 (genauer gesagt von jedem der jeweiligen Sicherheitsperipheriegeräte 32). So kann beispielsweise das Sicherheitsperipheriegerät 32 konfiguriert sein, um einen Zähler-ID-Status als Antwort auf eine Anforderung von dem Diagnosecomputer 20 bereitzustellen. Somit kann der Computer 20 diese Zähler-ID-Werte durch die Verbindungen 42, 44 empfangen. Wie vorstehend erörtert, kann die Zähler-ID jedes Peripheriegeräts 32 in Abhängigkeit von seinem anfänglichen Zählerwert, die Menge der Nachrichten, die durch die jeweilige ECU 26 (oder VSM 24) auf die Verbindung 22 übertragen werden, wie der jeweilige Zähler inkrementiert wird (z.B. durch irgendwelche oder durch irgendeine andere Menge oder algebraischen Ausdruck), um nur einige Beispiele zu nennen. Zähler-ID-Werte für jedes Sicherheits-Peripheriegerät 32 können in dem Speicher 48 (am Computer 20) gespeichert sein.
Schritt 320 kann auch das Empfangen anderer Daten beinhalten. So kann beispielsweise (wie vorstehend erläutert), der Computer 20 Daten empfangen und speichern, die angeben, welche kryptographischen Algorithmen in dem Fahrzeug 12 verwendet werden, Daten, die angeben, welche Schlüssel (oder Satz von Schlüsseln) an den ECU-Sicherheitsperipherien 32 oder beides verwendet werden.
Nach dem Anfangsschritt 305 (und Schritt 320) kann eine verschlüsselte Nachricht 70 von dem ersten Computer 16 empfangen werden. Da der erste Computer 16 nicht konfiguriert sein kann, um die Echtheit der Nachricht 70 zu validieren, kann er als Dateneingabe an den Computer 20 weitergegeben werden (Schritt 330). Somit kann der Computer 16 in mindestens einer Ausführungsform einer Filterfunktion dienen – z.B. durch den verschlüsselten Nachrichtenverkehr zum Diagnosecomputer 20. Wie vorstehend erläutert, kann der Computer 16 keine Schlüssel, kryptographische Algorithmen, Testanweisungen oder dergleichen tragen oder speichern; auch wenn der Computer 16 einige kryptographische Techniken verwendet hat, wird in Betracht gezogen, dass der Computer 16 aufgrund der Architektur und des Entwurfs des Kommunikationssystems 14 die Nachricht 70 nicht entschlüsseln konnte, da es nicht in der Lage wäre, den entsprechenden Schlüssel und/oder Algorithmus zu identifizieren, um dies zu tun. So sind beispielsweise die kommerziellen Beispiele (CANoe und Vehicle Spy) nicht so konfiguriert, dass sie die Nachricht 70 entschlüsseln. Es sollte erkannt werden, dass unverschlüsselte Nachrichten, die über die Netzwerkverbindung 22 gesendet werden, jedoch unter Verwendung des ersten Computers 16 (z.B. in mindestens einer Ausführungsform) ausgewertet werden können.
In Schritt 335, der dem Schritt 330 folgt, bestimmt der zweite Computer 20 – oder genauer gesagt, der Prozessor 46 – bestimmt einen geeigneten Schlüssel, um die Nachricht 70 zu entschlüsseln. Es sollte erkannt werden, dass die Anweisungen 60 die Sicherheitsperipherieanweisungen imitieren können – z.B. gemäß den Anweisungen 60, extrahiert der Computer 20 den Zähler-ID-Wert aus dem Header der Nachricht 70 und schaut im Speicher 48 einen zugeordneten Entschlüsselungsschlüssel auf. In mindestens einer Ausführungsform kann dieser Schlüssel ein symmetrischer Schlüssel sein (z.B. derselbe Schlüssel, der von dem Senderperipheriegerät 32 verwendet wird, um die Nachricht 70 zu verschlüsseln). Der Zähler-ID-Wert kann vom Prozessor 46 verwendet werden, um den geeigneten Entschlüsselungsschlüssel in einer im zweiten Computerspeicher 48 gespeicherten Nachschlagtabelle zu identifizieren – z.B. Auswählen der Taste, die dem Zähler-ID-Wert entspricht. Schritt 335 kann ferner den Prozessor 46 beinhalten, der eine ECU-Kennung aus der Nachricht 70 extrahiert (was anzeigt, welche ECU 26 die Nachricht gesendet hat) und mit dieser Kennung den entsprechenden Schlüssel in der Nachschlagetabelle identifizieren, um festzustellen, ob die Nachricht gültig ist oder beides.
Danach bestimmt der Prozessor 46 im Schritt 340, ob die Nachricht 70 validiert werden soll. Der Prozessor 46 extrahiert beispielsweise gemäß den Anweisungen 60 den MAC aus dem Hauptteil der Nachricht 70 und entschlüsselt ihn unter Verwendung des in Schritt 335 ausgewählten Schlüssels. Wenn der MAC nicht entschlüsselt werden kann, wird die Nachricht nicht validiert. Wenn jedoch der MAC entschlüsselt wird, vergleicht der Prozessor 46 den entschlüsselten Inhalt mit dem unverschlüsselten Nachrichteninhalt im Hauptteil der Nachricht. Wenn der entschlüsselte Inhalt mit dem unverschlüsselten Inhalt übereinstimmt, validiert der Prozessor 46 die Nachricht 70. Andernfalls wird die Nachricht 70 nicht validiert.
In dem nachfolgenden Schritt 345 liefert der Computer 20 Ausgabedaten 80 in Bezug auf die Nachricht 70 (z.B. eine PASS- oder FAIL-Ausgabe, wie in 2 gezeigt). Nicht beschränkende Beispiele der Ausgabe beinhalten das Anzeigen der Ausgabe auf einem Computermonitor, das Exportieren in einen Bericht oder ein Protokoll (z.B. mit oder ohne Validierungsdaten eines anderen Nachrichtenverkehrs) und dergleichen. Auf diese Weise kann ein Lieferant den zweiten Computer 20 mit dem Fahrzeug 12 (z.B. über den Computer 16) verbinden, die Anwendungssoftware 50 unter Verwendung des Computers 20 ausführen und kann für jeden verschlüsselten Nachrichtenverkehr, der über die Netzwerkverbindung 22 übertragen wird, Validierungsdaten empfangen. Weiterhin können alle diese Schritte auftreten, ohne dass der Lieferant Zugang zu vertraulichen Daten innerhalb der Sicherheitsperipheriegeräte 32 des Fahrzeugs 12 gewährt, wodurch die Gesamtsicherheit des Fahrzeugs verbessert wird.
Es sind auch andere Ausführungsformen vorhanden. So kann beispielsweise der Computer 20 (z.B. Prozessor 46) eine Nachricht mit verschlüsseltem Inhalt auf die Fahrzeugverbindung 22 übertragen – z.B. für eine oder mehrere VSMs 24 vorgesehen. Unter Verwendung herkömmlicher Verfahren wäre dies nicht möglich – z.B. ist der erste Computer 16 nicht dafür ausgelegt, eine derartige Verschlüsselung durchzuführen. In einigen Fällen kann diese Nachricht, die von dem Computer 20 übertragen wird, ein Versuch sein, eine Antwort von einem der VSMs 24 zu induzieren – z.B. um die Funktionalität eines Ziel-VSM zu testen, worin das Testen der Funktionalität eine Verschlüsselung erfordert. Nach dem Empfang durch das Ziel-VSM 24 kann das Sicherheits-Peripheriegerät 32 darin die Nachricht entschlüsseln, und unter bestimmten Umständen kann das VSM 24 eine verschlüsselte Nachricht als Antwort senden, die von dem Diagnosecomputer 20 gemäß den Schritten 325–345 empfangen werden kann.
In einer anderen Ausführungsform enthalten die VSMs 24 keine Sicherheitsperipheriegeräte 32. Dies kann zum Beispiel bei einigen Altfahrzeugen 12 auftreten. In diesen Ausführungsformen werden kryptographische Daten (z.B. eine oder mehrere Schlüssel, Algorithmen usw.) in dem Speicher 30 gespeichert und sind unter Verwendung des Prozessors 28 ausführbar (z.B. um eine beliebige Verschlüsselung/Entschlüsselung durchzuführen). Somit kann die Anwendungsbibliothek 50 in mindestens einer Ausführungsform derartige Legacy-Fahrzeuge identifizieren, die einen Identifizierer oder andere geeignete Mittel verwenden und den geeigneten Algorithmus und/oder Schlüssel(n) bestimmen, die bei der Entschlüsselung des Nachrichtenverkehrs davon verwendet werden sollen.
In einigen Ausführungsformen kann der Hersteller die Anwendungsbibliothek 50 dem Lieferanten zur Verfügung stellen, damit der Lieferant die Bibliothek auf dem Diagnosecomputer 20 installieren kann. So kann beispielsweise der Hersteller die Anwendungssoftware auf einer CD-ROM, einem Flash-Laufwerk oder einem anderen geeigneten Medium bereitstellen; oder der Hersteller kann die Software zum Download über einen Computer-Server oder dergleichen zur Verfügung stellen. Natürlich sind dies lediglich Beispiele; andere existieren. So kann beispielsweise der Hersteller in einer anderen Ausführungsform einen Diagnosecomputer 20 mit der darauf installierten Anwendungsbibliothek 50 bereitstellen. In dieser Ausführungsform kann der Hersteller die Bibliothek in einem separaten Speicher aufteilen – z.B. ausführbar durch einen dedizierten Prozessor oder eine Verarbeitungsschaltung.
In einer anderen Ausführungsform können die Computer 16 und 20 zu einem einzigen Gerät oder Computer konfiguriert sein. In diesem Fall kann eine einzige Diagnoseeinrichtung mit der Verbindung 22 in jeder geeigneten Weise verbunden sein – z.B. mittels Draht oder drahtlos. Es sollte erkannt werden, dass jede der hierin offenbarten Ausführungsformen einzeln oder in Kombination mit anderen offenbarten Ausführungsformen verwendet werden kann.
Somit wurde ein Fahrzeugtestkommunikationssystem beschrieben, das einen Diagnosecomputer mit einer Softwareanwendung beinhaltet, die eine Nachrichtenauthentifizierungs-Bibliothek beinhaltet. Der Diagnosecomputer ist so konfiguriert, dass er Nachrichtenverkehr vom Fahrzeug empfängt – in einigen Fällen über einen anderen Computer. Danach wird unter Verwendung der Bibliothek der Diagnosecomputer konfiguriert, um zu bestimmen, ob der verschlüsselte Nachrichtenverkehr, der über das Fahrzeugnetzwerk gesendet wird, gültig ist oder nicht, und einen geeigneten Bericht bereitstellt. Die Bibliothek kann auch angepasst werden, um andere Funktionen auszuführen; z.B. einschließlich des Sendens von verschlüsselten Testnachrichten auf die Netzwerkverbindung. Somit ermöglicht die Bibliothek dem Lieferanten, zu bestimmen, ob verschlüsselte Nachrichten, die über die Verbindung gesendet werden, gültig sind, ohne dem Lieferanten die kryptographischen Daten oder Informationen zur Verfügung zu stellen, die zur Teilnahme an irgendwelchen Verschlüsselungs- oder Entschlüsselungsprozessen erforderlich sind. Somit kann der Lieferant, sobald die Anwendungssoftware auf dem Diagnosecomputer installiert ist, eine Angabe empfangen, ob verschlüsselte Nachrichten, die über die Fahrzeugverbindung gesendet werden, gültig sind oder nicht.
Es versteht sich, dass das Vorstehende eine Beschreibung einer oder mehrerer Ausführungsformen der Erfindung ist. Die Erfindung ist nicht auf die besondere(n) hierin offenbarte(n) Ausführungsform(en) beschränkt, sondern ausschließlich durch die folgenden Patentansprüche definiert. Darüber hinaus beziehen sich die in der vorstehenden Beschreibung gemachten Aussagen auf bestimmte Ausführungsformen und sind nicht als Einschränkungen des Umfangs der Erfindung oder der Definition der in den Patentansprüchen verwendeten Begriffe zu verstehen, außer dort, wo ein Begriff oder Ausdruck ausdrücklich vorstehend definiert wurde. Verschiedene andere Ausführungsformen und verschiedene Änderungen und Modifikationen an der/den ausgewiesenen Ausführungsform(en) sind für Fachleute offensichtlich. Alle diese anderen Ausführungsformen, Änderungen und Modifikationen sollten im Geltungsbereich der angehängten Patentansprüche verstanden werden.
Wie in dieser Spezifikation und den Patentansprüchen verwendet, sind die Begriffe „z. B.“, „beispielsweise“, „zum Beispiel“, „wie z.B.“ und „wie“ und die Verben „umfassend“, „einschließend“ „aufweisend“ und deren andere Verbformen, wenn sie in Verbindung mit einer Auflistung von einer oder mehreren Komponenten oder anderen Elementen verwendet werden, jeweils als offen auszulegen, was bedeutet, dass die Auflistung andere zusätzliche Komponenten oder Elemente nicht ausschließt. Andere Begriffe sind in deren weitesten vernünftigen Sinn auszulegen, es sei denn, diese werden in einem Kontext verwendet, der eine andere Auslegung erfordert.

Claims

Computerprogrammprodukt, umfassend: ein nichtflüchtiges computerlesbares Medium für einen Diagnosecomputer umfassend ein Anwendungssoftwareprogramm, das Anweisungen beinhaltet, die angepasst sind, um verschlüsselte Nachrichten zu validieren, die über eine Fahrzeugnetzwerkverbindung übertragen werden, worin die Anweisungen umfassen: Durchführen einer Initialisierungssequenz, die das Empfangen von Initialisierungsdaten an dem Diagnosecomputer beinhaltet, worin die Initialisierungsdaten mit einer Vielzahl von Fahrzeugsystemmodulen (VSMs) verbunden sind, die über die Fahrzeugnetzverbindung miteinander verbunden sind; Empfangen als Dateneingabe am Diagnosecomputer eine verschlüsselte Nachricht, die über die Netzwerkverbindung übertragen wird; und basierend auf den Initialisierungsdaten, Bestimmen an dem Diagnosecomputer, ob die empfangene verschlüsselte Nachricht gültig ist.
Computerprogrammprodukt nach Anspruch 1, worin die Anweisungen ferner das Bereitstellen von Ausgabedaten an dem Diagnosecomputer umfassen, die beinhalten, ob die empfangene verschlüsselte Nachricht gültig oder ungültig war.
Computerprogrammprodukt nach Anspruch 2, worin die Ausgabedaten entweder Pass oder Fail sind.
Computerprogrammprodukt nach Anspruch 1, worin der Diagnosecomputer die Initialisierungsdaten und die verschlüsselte Nachricht über einen zweiten Diagnosecomputer empfängt, der ferner mit der Netzwerkverbindung gekoppelt ist, worin beide Diagnosecomputer Nichtfahrzeuggeräte sind.
Computerprogrammprodukt nach Anspruch 1, worin die Anweisungen ferner das Speichern der Initialisierungsdaten im Speicher an dem Diagnosecomputer umfassen.
Computerprogrammprodukt nach Anspruch 1, worin die Initialisierungsdaten einen Zähleridentifiziererwert (ID) umfassen, der jeder der Vielzahl von VSMs zugeordnet ist, worin jeder der Zähler-ID-Werte einer Menge von verschlüsselten Nachrichten zugeordnet ist, die von jeder der Vielzahl von VSMs übertragen werden.
Computerprogrammprodukt nach Anspruch 1, worin die Initialisierungsdaten eine Vielzahl von Zähleridentifizierungswerten (ID) umfassen, worin jeder der Vielzahl von Zähler-ID-Werten einem einzigen kryptographischen Schlüssel zugeordnet ist, worin die verschlüsselte Nachricht einen Zähler-ID-Wert umfasst, der mit einem der Vielzahl von Zähler-ID-Werten übereinstimmt.
Computerprogrammprodukt nach Anspruch 7, worin der Bestimmungsschritt in den Anweisungen ferner den Diagnosecomputer umfasst, der den einzelnen kryptographischen Schlüssel identifiziert, wobei der in der verschlüsselten Nachricht empfangene Zähler-ID-Wert verwendet wird und danach der einzige kryptographische Schlüssel verwendet wird, um die verschlüsselte Nachricht zu validieren.
Computerprogrammprodukt nach Anspruch 1, worin die verschlüsselte Nachricht unverschlüsselte Inhaltsdaten und einen Nachrichtenauthentifizierungscode (MAC) beinhaltet, worin der MAC eine verschlüsselte Version der Inhaltsdaten beinhaltet.
Verfahren zur Validierung einer verschlüsselten Nachricht an einen Diagnosecomputer über eine Fahrzeugnetzwerkverbindung, umfassend die Schritte: Empfangen von Initialisierungsdaten an dem Diagnosecomputer, worin die Initialisierungsdaten von einer Vielzahl von Fahrzeugsystemmodulen (VSMs) empfangen werden, die über die Fahrzeugnetzverbindung miteinander verbunden sind; Empfangen einer verschlüsselten Nachricht an dem Diagnosecomputer, worin die verschlüsselte Nachricht von einer der Vielzahl von VSMs über die Netzwerkverbindung übertragen wurde; basierend auf den Initialisierungsdaten, Bestimmen an dem Diagnosecomputer, ob die empfangene verschlüsselte Nachricht gültig ist; und Bereitstellen von Ausgabedaten an dem Diagnosecomputer, die anzeigen, ob die empfangene verschlüsselte Nachricht gültig oder ungültig war.