DE102004063319A1

DE102004063319A1 - Vorrichtung und Verfahren zur Überprüfung fahrzeuginterner Software-Komponenten

Info

Publication number: DE102004063319A1
Application number: DE102004063319A
Authority: DE
Inventors: Amer Aijaz
Original assignee: Volkswagen AG
Current assignee: Volkswagen AG
Priority date: 2004-12-23
Filing date: 2004-12-23
Publication date: 2006-07-13

Abstract

Ein Fahrzeug soll durch ein kostengünstiges Konzept wirksam gegen Hacker-Angriffe geschützt werden. Hierzu wird ein Verfahren zur Überprüfung mindestens einer Software-Komponente in einem Fahrzeug durch Bilden eines Kontrollwerts bezüglich der mindestens einen Software-Komponente, Übermitteln des Kontrollwerts an eine fahrezugexterne Recheneinheit (DM) und Vergleichen des übermittelten Kontrollwerts mit einem vorgegebenen, in der fahrzeugexternen Recheneinheit (DM) abgelegten Vergleichswert. Damit kann festgestellt werden, ob Software-Komponenten im Fahrzeug unbefugt geändert oder gelöscht wurden.

Description

Die vorliegende Erfindung betrifft ein Verfahren zur Überprüfung mindestens einer Software-Komponente in einem Fahrzeug. Darüber hinaus betrifft die vorliegende Erfindung eine entsprechende Vorrichtung.

Fahrzeuge nutzen Recheneinrichtungen zum elektronischen Steuern vieler Komfort- und Antriebsfunktionen. Üblicherweise sind diese Recheneinrichtungen integrierte Einheiten, die für einen speziellen Einsatz ausgestaltet sind. In letzter Zeit werden für Fahrzeuge auch sogenannte Allzweckcomputer eingesetzt. Diese Allzweckcomputer werden üblicherweise als Telematiceinheiten oder On-Board-Computer bezeichnet. Sie sind üblichen Personalcomputern (PCs) ähnlich und meist nur in der Verarbeitungs- und Speicherkapazität beschränkt. Der Vorteil der Verwendung eines PC-ähnlichen Allzweckcomputers besteht darin, dass er einen allgemein einsetzbaren Allzweckprozessor und ein Allzweckbetriebssystem besitzt, auf denen PC-kompatible Applikationen laufen können.

Einerseits besteht der Vorteil dieser Allzweckcomputer für Automobilhersteller und Dritte darin, dass neue, interessante Applikationen für den Fahrer entwickelt und eingesetzt werden können. Andererseits öffnen Allzweckcomputer das Tor für Hacker, die ihre unerwünschte Software auf den Allzweckcomputern in den Fahrzeugen ablaufen lassen können.

Ein Hacker kann somit seine eigene Software auf diesen Allzweckcomputern installieren, um das Verhalten der Antriebsassistenz des Fahrzeugs oder Komfort- und Infotainment-Funktionalitäten zu ändern. Eine Änderung der Eigenschaften dieser Funktionalitäten kann zu Unbehagen des Fahrers bzw. der Passagiere und im schlimmsten Fall zu einem Unfall führen.

Theoretisch könnten die Allzweckcomputer fälschungssicher gemacht und die Betriebssysteme so entworfen werden, dass die Hacker keine Möglichkeit haben, in diese Systeme einzudringen. In der Praxis wird diese Fälschungssicherheit bzw. Unzugänglichkeit stets eine Frage des Kostenaufwands sein. Daher ist es realistisch, dass ein Hacker stets die Möglichkeit haben wird, auf einem Computer zuzugreifen und seine eigene Applikationssoftware darauf zu installieren oder alternativ wesentliche Softwarekomponenten auf dem Computer zu ersetzen oder zu löschen.

In diesem Zusammenhang ist aus der Druckschrift EP 1 127 756 A2 ein Autorisierungsverfahren mit Zertifikat bekannt. Darüber hinaus beschreibt die Druckschrift WO 01/85494 A2 ein Verfahren zum Zugriff auf ein Gerät eines Kommunikationsnetzes in einem Kraftfahrzeug durch ein externes Gerät und Gateway. Schließlich offenbart die Europäische Patentschrift EP 0 675 024 B1 ein Fahrzeuglokalnetz und ein neu entwickeltes Nachrichtenleitweglenkungsverfahren.

Die Aufgabe der vorliegenden Erfindung besteht darin, ein kostengünstiges Konzept zu entwickeln, mit dem Fahrzeuge vor Hacker-Angriffen geschützt werden können.

Erfindungsgemäß wird diese Aufgabe durch ein Verfahren nach Anspruch 1 gelöst. Außerdem ist erfindungsgemäß eine entsprechende Vorrichtung nach Anspruch 8 vorgesehen.

Vorteilhafte Weiterentwicklungen dieses Verfahrens und dieser Vorrichtung ergeben sich aus den Unteransprüchen.

Die vorliegende Erfindung wird nun anhand der beigefügten Zeichnungen näher erläutert, in denen zeigen:
1 ein Prinzipschaltbild einer erfindungsgemäßen Vorrichtung und
2 ein Prinzipschaltbild zur Erzeugung eines sicheren Kontrollwerts.
Die nachfolgend näher geschilderten Ausführungsbeispiele stellen bevorzugte Ausführungsformen der vorliegenden Erfindung dar.
Der Erfindung liegt die Kenntnis zugrunde, dass im Fahrzeug installierte Altzweckcomputer stets für Hacker-Angriffe anfällig sein werden. Wenn nun die Automobilhersteller kein System entwickeln können, das vollständig fälschungssicher ist, können sie zumindest ein Fälschungsdetektionssystem entwickeln, um auf Fälschungsangriffe zu reagieren.
Ein entsprechendes System ist schematisch in 1 dargestellt. Das Konzept basiert darauf, dass ein Fahrzeug F mit einer Telematiceinheit TU über ein Weitverkehrsnetz, z. B. GSM/GPRS, mit der Datenbank eines Automobilherstellers DM gegebenenfalls über eine Firewall F/W verbunden ist. Die Telematiceinheit TU besteht aus mehreren Applikationen A1 – An, die mit einem Betriebssystem OS betrieben werden können. Außerdem sind geeignete Schnittstellen zu einem fahrzeuginternen Bus, z. B. CAN, zu einem lokalen Netzwerk, z. B. WLAN und zu einem Weitverkehrsnetz, z. B. GSM/GPRS, vorgesehen. Zur sicheren Kommunikation über ein GSM/GPRS-Netz kann ein VPN-Tunnel (virtual private network) VT zwischen dem Fahrzeug und dem Hersteller oder dergleichen verwendet werden.
Während der Herstellung des Fahrzeugs oder während der Installation, Reparatur oder Aktualisierung des fahrzeuginternen Computers berechnet der Hersteller einen Referenz-Hash-Wert bezüglich aller Software-Applikationen und "Daemons" (disk and execution monitor), die auf dem fahrzeuginternen Computer installiert sind. Dieser Referenz-Hash-Wert wird in einer zentralen Datenbank des Herstellers gespeichert.
Ein Hash-Wert ist eine einzigartige Ziffer, d. h. ein Kontrollwert, der zu einem Informationssatz berechnet wird. Hash-Werte werden mit speziellen mathematischen Funktionen, den sogenannten "Hash-Funktionen", berechnet. Hash-Funktionen sind mathematische Funktionen, die einen Informationssatz als Eingang verwenden und die eine "einzigartige Ziffer", welche die eingegebenen Informationen repräsentiert, ausgeben. Hash-Funktionen sind Einwegfunktionen. Dies bedeutet, dass aus einem Hash-Wert nicht die Originalinformation, die zur Berechnung des Hash-Wertes verwendet wurde, wieder gewonnen werden kann.
Zur sicheren Übertragung kann der Hash-Wert, der im Fahrzeug berechnet wurde, mit einem Schlüssel einer PKI-Infrastruktur verschlüsselt und mit einem korrespondierenden, anderen Schlüssel beim Empfänger wieder entschlüsselt werden. Im Fall symmetrischer Verschlüsselung sind die Schlüssel zum Verschlüsseln und Entschlüsseln gleich. Wenn jedoch asymmetrische Verschlüsselung gewählt wird, wird mit einem „privaten Schlüssel" verschlüsselt und mit einem „öffentlichen Schlüssel" entschlüsselt. Obwohl die asymmetrische Verschlüsselung rechenzeitintensiv ist, hat sie den Vorteil, dass sie schwieriger zu „knacken" ist als eine symmetrische Verschlüsselung.
In 2 ist schematisch dargestellt, wie aus den in der Telematiceinheit TU installierten Applikationen ein asymmetrisch verschlüsselter Hash-Wert SHV gewonnen wird. Zunächst wird aus der Liste der Applikationen A1 bis An mit Hilfe einer Hash-Funktion HFU ein Hash-Wert HV ermittelt, der in 2 mit 12345 symbolisiert ist. Aus dem Hash-Wert HV wird dann durch eine Verschlüsselungsfunktion EFU mit einem privaten Schlüssel PRK ein verschlüsselter Hash-Wert SHV kreiert, der in 2 mit rfths642 symbolisiert ist. Der private Schlüssel PRK soll für jedes Fahrzeug einzigartig sein. Daher sollte der Hersteller zum Zeitpunkt der Herstellung ein einzigartiges Schlüsselpaar bestehend aus einem privaten Schlüssel und einem öffentlichen Schlüssel erzeugen. Der private Schlüssel soll in dem Fahrzeug derart gespeichert werden, dass nur die Telematikeinheit TU ihn lesen kann. Keiner, auch nicht die Telematikeinheit TU, soll den privaten Schlüssel ändern können. Der entsprechende öffentliche Schlüssel sollte in einer zentralen Datenbank des Herstellers zusammen mit Herstellungsidentifikationsdaten und dem Referenz-Hash-Wert des Fahrzeugs gespeichert werden.
Nach dem Verkauf sollte das Fahrzeug von Zeit zu Zeit den verschlüsselten Hash-Wert zur gesamten auf dem Allzweckcomputer installierten Software neu berechnen und diesen verschlüsselten Hash-Wert über eine sicherer Verbindung eines Weitverkehrsnetzes, z. B. GSM/GPRS, UMTS, W-LAN Hots Spots, etc., an den Hersteller senden. Nach Empfang des verschlüsselten Hash-Werts entschlüsselt der Hersteller den Hash-Wert und vergleicht diesen mit dem Referenz-Hash-Wert, der als Vergleichswert in seiner Datenbank gespeichert ist. Wenn die beiden Hash-Werte nicht übereinstimmen, bedeutet dies, dass entweder eine nicht autorisierte Software in dem Fahrzeug installiert wurde oder zumindest eine der Software-Applikationen oder "Daemons", die in dem Fahrzeugcomputer installiert waren, ersetzt oder gelöscht wurden.
Wenn der Hersteller feststellt, dass die auf dem Fahrzeugcomputer installierten Software-Applikationen oder "Daemons" abgeändert oder gelöscht wurden, kann er eine Ferndiagnose des Systems durchführen und dieses gegebenenfalls abschalten, um Nachteile für den Fahrer zu vermeiden.
Eine weitere Unsicherheit besteht darin, dass ein Hacker die Software in dem Allzweckcomputer, die für die Berechnung des sicheren Hash-Werts für alle Applikationen und "Daemons" verantwortlich ist, ersetzen oder löschen könnte. Wenn der Hacker hierzu in der Lage ist, kann der Hersteller nicht sicher sein, ob der von ihm empfangene Hash-Wert ein gefälschter Wert oder ein tatsächlicher für alle Applikationen "Daemons" berechneter Wert ist. Deswegen kann entsprechend einer Weiterentwicklung vorgesehen sein, dass die Software zur Berechnung des Hash-Werts nicht in dem Allzwecksystem installiert ist, sondern in einem kleinen, speziellen, fälschungssicheren Gerät innerhalb des Fahrzeugs.
Eine alternative und gegebenenfalls bessere Lösung besteht darin, dass der Allzweckcomputer eine Laufzeitumgebung aufweist, mit der ein mobiler Code, z. B. eine sogenannte Mobile Agent-Plattform, handhabbar ist. Der Hersteller kann dann die Applikation als mobilen Code an den Allzweckcomputer des Fahrzeugs senden. Der mobile Code wird daraufhin den Hash-Wert berechnen und nach erfolgter Berechnung an den Hersteller zurückgesandt werden. Dieser Ansatz hat den Vorteil, dass der mobile Code nicht permanent in dem Fahrzeug installiert ist und daher von einem Hacker nicht abänderbar oder löschbar ist.

A1 – An: Applikationen
CAN: fahrzeuginterner Bus
DM: Datenbank eines Automobilherstellers
EFU: Verschlüsselungsfunktion
F: Fahrzeug
F/W: Firewall
GSM/GPRS: Weitverkehrsnetz
HFU: Hash-Funktion
HV: Hash-Wert
OS: Betriebssystem
PRK: privater Schlüssel
SHV: sicherer Hash-Wert
TU: Telematiceinheit
VT: VPN-Tunnel
WLAN: lokales Netzwerk

Claims

Verfahren zur Überprüfung mindestens einer Sotftware-Komponente (A1 bis An) in einem Fahrzeug (F) durch – Bilden eines Kontrollwerts (SHV) bezüglich der mindestens einen Software-Komponente (A1 bis An), – Übermitteln des Kontrollwerts (SHV) an eine fahrzeugexterne Recheneinheit (DM) und – Vergleichen des übermittelten Kontrollwerts (SHV) mit einem vorgegebenen, in der fahrzeugexternen Recheneinheit (DM) abgelegten Vergleichswert.
Verfahren nach Anspruch 1, wobei der Kontrollwert (SHV) eine mehrstellige Ziffer oder Ziffer-Buchstaben-Kombination ist, die aus den Identitäten, Typen und/oder Versionen mehrerer Software-Komponenten ermittelt wird.
Verfahren nach Anspruch 1 oder 2, wobei der Kontrollwert (SHV) vor der Übermittlung mit einem privaten Schlüssel (PRK) verschlüsselt wird.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die Übermittlung des Kontrollwerts (SHV) über ein Mobilfunknetz erfolgt.
Verfahren nach einem der vorhergehenden Ansprüche, wobei eine oder mehrere Software-Komponenten (A1 bis An) im Fahrzeug (F) ferngesteuert repariert oder abgeschaltet werden.
Verfahren nach einem der vorhergehenden Ansprüche, wobei eine fahrzeuginterne Recheneinrichtung (TU) zur Bildung des Kontrollwerts (SHV) eine von anderen Fahrzeugkomponenten unabhängige Einheit ist.
Verfahren nach einem der vorhergehenden Ansprüche, wobei der Kontrollwert (SHV) mit einem mobilen Code gebildet wird.
Vorrichtung zur Überprüfung mindestens einer Software-Komponente (A1 bis An) in einem Fahrzeug (F) mit – einer fahrzeuginternen Recheneinrichtung (TU) zum Bilden eines Kontrollwerts (SHV) bezüglich der mindestens einen Software-Komponente (A1 bis An), – einer fahrzeugexternen Recheneinrichtung (DM) zum Speichern eines vorgegebenen Vergleichswerts und zum Vergleichen des Kontrollwerts (SHV) mit dem Vergleichswert und – einer Übermittlungseinrichtung (VT) zur Übermittlung des Kontrollwerts (SHV) von der fahrzeuginternen (TU) zu der fahrzeugexternen Recheneinrichtung (DM).
Vorrichtung nach Anspruch 8, wobei der Kontrollwert (SHV) eine mehrstellige Ziffer oder Ziffer-Buchstaben-Kombination ist, die durch die fahrzeuginterne Recheneinrichtung (TU) aus den Identitäten, Typen und/oder Versionen mehrerer Software-Komponenten (A1 bis An) ermittelbar ist.
Vorrichtung nach Anspruch 8 oder 9, wobei die fahrzeuginterne Recheneinrichtung (TU) eine Verschlüsselungseinheit (EFU) umfasst.
Vorrichtung nach einem der Ansprüche 8 bis 10, wobei die Übermittlungseinrichtung (VT) ein Mobilfunknetz umfasst.
Vorrichtung nach einem der Ansprüche 8 bis 11, wobei die fahrzeuginterne Recheneinrichtung (TU) eine von anderen Fahrzeugkomponenten unabhängige Einheit ist.
Vorrichtung nach einem Ansprüche 8 bis 12, wobei die fahrzeuginterne Recheneinrichtung (TU) eine Laufzeitumgebung aufweist, in der ein mobiler Code ausführbar ist.