-
Die
Erfindung betrifft ein Verfahren zur Übertragung von Daten
zwischen einem Rechner eines Kraftfahrzeugs und einem zentralen
Rechner eines Rechnernetzwerks. Die Erfindung betrifft ferner einen Rechner
eines Kraftfahrzeugs sowie ein Kommunikationsnetzwerk, das zumindest
einen Rechner eines Kraftfahrzeugs und einen zentralen Rechner umfasst.
-
Der
zentrale Rechner des Rechnernetzwerks ist beispielsweise ein Rechner
eines IT-Netzwerks des Kraftfahrzeugherstellers oder eines Dienstleisters
des Kraftfahrzeugherstellers. Eine Datenübertragung zwischen
dem Rechner des Kraftfahrzeugs und dem zentralen Rechner des Rechnernetzwerks
wird beispielsweise bei der Nutzung von internetbasierten Diensten,
wie z. B. Karten oder Office-Anwendungen, dem Bezug von Software-Aktualisierungen
durch den Nutzer des Kraftfahrzeugs sowie zu Diagnosezwecken benötigt.
Die Datenübertragung zwischen dem Rechner des Kraftfahrzeugs
und dem zentralen Rechner des Rechnenetzwerks erfolgt über
eine drahtlose Kommunikationsverbindung, wie z. B. WLAN
(Wireless Local Area Network), GSM (Global System
for Mobile Communications), UMTS (Universal Mobile
Telecommunications System) oder ähnliche Kommunikationsstandards.
Aufgrund der drahtlosen Kommunikationsverbindung muss sichergestellt
sein, dass eine Datenübertragung zwischen dem tatsächlich
beabsichtigten und berechtigten zentralen Rechner des Kraftfahrzeugs
und dem zentralen Rechner des Kommunikationsnetzwerks erfolgt. Zum
einen muss sichergestellt werden, dass das Einsehen und die Nutzung
von Daten nur in einem berechtigten Kraftfahrzeug möglich
ist. Andererseits muss insbesondere bei der Telediagnose oder der
Teleprogrammierung sichergestellt sein, dass Daten von dem richtigen
Fahrzeug empfangen und vom berechtigten zentralen Rechner übermittelt
werden. In einem Fehlerfall könnten ansonsten Funktionsstörungen
auftreten.
-
Aus
dem Bereich von Rechnernetzwerken sind verschiedene Technologien
zur Identifikation und Authentisierung zweier miteinander kommunizierender
Rechner (sog. Entitäten) bekannt. Eine Technologie zur
Authentisierung, basierend auf kryptographischen Protokollen, ist
beispielsweise aus dem Standard ISO 9798 von 1998 bekannt.
Diese Technologie wird z. B. bei der sicheren Kommunikation bei Webanwendungen,
wie z. B. beim Online-Banking, eingesetzt.
-
Darüber
hinaus ist es aus den Standards ISO 15764 und IEEE
1609.2 bekannt, Kommunikationsverbindungen zwischen zwei Entitäten
abzusichern. Die Absicherung erfolgt hierbei auf einer Nachrichtenebene.
-
Die
beschriebenen Sicherheitstechnologien betreffen hierbei jedoch klassische
Rechnernetzwerke, die die Besonderheiten bei der Datenübertragung zu
einem Kraftfahrzeug nicht berücksichtigen bzw. sich lediglich
auf den Aspekt der Absicherung einzelner Nachrichten beziehen.
-
Es
ist daher Aufgabe der vorliegenden Erfindung, ein Datenübertragungsverfahren
anzugeben, welches eine hohe Sicherheit beim Datenaustausch zwischen
dem Rechner eines Kraftfahrzeugs und eines zentralen Rechners eines
Rechnernetzwerks sicherstellt. Ferner soll ein Rechner eines Kraftfahrzeugs
angegeben werden. Eine weitere Aufgabe besteht darin, ein Kommunikationsnetzwerk
mit einem Rechner eines Kraftfahrzeugs und einem zentralen Rechner
eines Rechnernetzwerkes anzugeben, welches eine hohe Sicherheit
bei der Datenübertragung bereitstellt.
-
Diese
Aufgaben werden durch ein Verfahren mit den Merkmalen des Patentanspruches
1, einen Rechner mit den Merkmalen des Patentanspruches 22 sowie
ein Kommunikationsnetzwerk mit den Merkmalen des Patentanspruches
23 gelöst. Vorteilhafte Ausgestaltungen sind in den abhängigen
Patentansprüchen angegeben.
-
Die
Erfindung schafft ein Verfahren zur Übertragung von Daten
zwischen einem Rechner eines Kraftfahrzeugs und einem zentralen
Rechner eines Rechnernetzwerks, bei dem der Verbindungsaufbau einer
Kommunikationsverbindung abgesichert erfolgt, und nur im Falle eines
erfolgreichen Verbindungsaufbaus die Datenübertragung aufgenommen wird.
-
Die
der Erfindung zu Grunde liegende Überlegung besteht darin,
die Absicherung bereits beim Verbindungsaufbau herzustellen. Lediglich
dann, wenn sichergestellt ist, dass die tatsächlich beabsichtigten
Kommunikationspartner vorliegen, wird eine Datenübertragung
aufgenommen. Aus Sicht des Rechnernetzwerks stellt dann der zentrale
Rechner des Kraftfahrzeugs eine Entität des Rechnernetzwerks
dar, mit dem über bekannte, abgesicherte Kommunikationsverfahren
Daten ausgetauscht werden können. Auf diese Weise ist es
möglich, Kraftfahrzeuge in eine übergreifende
Plattform, nämlich das Rechnernetzwerk, einzubinden, so
dass die Nutzung der abgesicherten Verbindung auf Ebene von Applikationen
möglich ist. Dies betrifft insbesondere das sog. Session
Management sowie Single-Sign Ons.
-
Unter
einem abgesicherten Verbindungsaufbau wird in der vorliegenden Erfindung
ein automatisiert ablaufender Prozess verstanden, welcher den Rechner
des Kraftfahrzeugs und den zentralen Rechner des Rechnernetzwerkes
wechselseitig in die Lage versetzt, zu überprüfen,
ob der jeweils gewünschte Kommunikationspartner am Aufbau
der Kommunikationsverbindung beteiligt ist. Hierbei ist sichergestellt,
dass es nicht möglich ist, eine andere Identität
vorzutäuschen. Abgesichert bedeutet weiterhin, dass eine
hohe Sicherheit gegenüber einer Manipulation vorliegt.
-
Zweckmäßigerweise
wird der Verbindungsaufbau durch den Rechner des Kraftfahrzeugs
initiiert. Dies bedeutet, zur Durchführung des abgesicherten
Verbindungsaufbaus ist das Eingreifen eines Nutzers nicht notwendig.
Dies schließt natürlich nicht aus, dass ein Nutzer
eines Kraftfahrzeugs, der eine von dem Rechnernetzwerk angebotene
Applikation nutzen möchte, den Anstoß dazu gibt,
diese durchzuführen.
-
Insbesondere
ist hierbei vorgesehen, dass die Absicherung des Verbindungsaufbaus
rechnergestützt ohne einen manuellen Eingriff oder eine
manuelle Eingabe eines Nutzers des Kraftfahrzeugs erfolgt. Dies
bedeutet, es ist insbesondere nicht notwendig, dass ein Nutzer des
Kraftfahrzeugs eine Kennung sowie ein Passwort eingibt. Vielmehr
ermöglicht es das erfindungsgemäße Verfahren,
den Verbindungsaufbau automatisiert nach dem Erhalt eines entsprechenden
Triggerereignisses vorzunehmen, ohne dass der Nutzer des Kraftfahrzeugs
hiervon etwas bemerkt. Hierdurch ist eine einfache Anwendbarkeit
gegeben. Ferner kann hiermit eine hohe Akzeptanz durch den Nutzer
des Kraftfahrzeugs erzielt werden.
-
Die
Absicherung des Verbindungsaufbaus umfasst eine Identifikation und/oder
eine Authentisierung des Kraftfahrzeugs durch den zentralen Rechner.
Alternativ oder zusätzlich umfasst die Absicherung des
Verbindungsaufbaus eine Identifikation und/oder eine Authentisierung
des Fahrers des Kraftfahrzeugs durch den zentralen Rechner. Die
Identifikation und die Authentisierung des Fahrers des Kraftfahrzeugs
sind insbesondere dann vor teilhaft, wenn Nutzerspezifische Informationen,
wie z. B. persönliche Emails, Kontaktdaten und dergleichen,
zwischen den Entitäten ausgetauscht werden. Im Falle der
eingangs erwähnten Telediagnose, mit der eventuell auftretende
Probleme an dem Kraftfahrzeug an den Automobilhersteller übertragen
werden sollen, ist hingegen eine fahrzeugspezifische Identifikation
ausreichend. Das erfindungsgemäße Verfahren ermöglicht
damit eine abgestufte Überprüfung von Identitäten
und deren Authentisierung.
-
Die
Datenübertragung zwischen dem Rechner des Kraftfahrzeugs
und dem zentralen Rechner des Rechnernetzwerkes erfolgt insbesondere über eine
drahtlose Kommunikationsverbindung. Mit anderen Worten bedeutet
dies, dass das erfindungsgemäße Verfahren im regulären
Betrieb des Kraftfahrzeugs zum Einsatz gelangen kann. Die Durchführung des
beschriebenen Verfahrens ist beispielsweise dann nicht notwendig
(aber natürlich dennoch durchführbar), wenn das
Kraftfahrzeug z. B. in der Werkstatt des Automobilherstellers mit
entsprechenden (Diagnose-)Rechnern verbunden ist. In diesem Fall ist
es gegebenenfalls entbehrlich, die Identität des Kraftfahrzeugs
und/oder des Fahrers/Nutzers des Kraftfahrzeugs zu überprüfen,
da dies vor Ort ohne Weiteres auf anderem Wege festgestellt werden kann.
-
Es
ist weiter vorgesehen, dass im Rahmen des Verbindungsaufbaus zumindest
ein fahrzeugspezifisches Datum zu dessen Identifikation von dem
Rechner des Kraftfahrzeugs an den zentralen Rechner übertragen
wird. Für die Absicherung des Verbindungsaufbaus wird zweckmäßigerweise
die Fahrzeugidentifikationsnummer, d. h. die Fahrgestellnummer,
verwendet, da diese für jedes hergestellte Fahrzeug einmalig
ist. Das zumindest eine fahrzeugspezifische Datum ermöglicht
es, die Identität des Kraftfahrzeugs zweifelsfrei feststellen
zu können.
-
Das
zumindest eine fahrzeugspezifische Datum umfasst ferner zweckmäßigerweise
ein möglichst unveränderliches Merkmal des Kraftfahrzeugs, insbesondere
eine Fahrzeugmodellbezeichnung, eine Karosserieform, eine Farbe
und/oder Art der Sitzpolsterung oder eine Farbe des Kraftfahrzeugs.
-
Das
zumindest eine fahrzeugspezifische Datum wird ferner in dem zentralen
Rechner des Rechnernetzwerks zur Überprüfung der
Plausibilität der Identität des Kraftfahrzeugs
und/oder des Fahrers des Kraftfahrzeugs verwendet, indem ein Vergleich mit
in dem Rechner für das Kraftfahrzeug gespeicherten Daten
erfolgt. Auf diese Weise kann beim Verdacht, dass das zur Absicherung
des Verbindungsaufbaus verwendete Fahren kompromittiert ist, überprüft
werden, ob tatsächlich das behauptete Kraftfahrzeug Kommunikationspartner
der beabsichtigten Datenübertragungsverbindung ist. Auf
diese Weise ist eine Verbesserung der Sicherheit im Rahmen des Verbindungsaufbaus
der Kommunikationsverbindung möglich.
-
Es
ist insbesondere vorgesehen, dass bei einer Mehrzahl von übermittelten
fahrzeugspezifischen Daten bei einer vorgegebenen Mindestanzahl
der Daten eine Übereinstimmung festgestellt werden muss.
Beispielsweise kann festgelegt werden, dass drei von fünf übermittelten
fahrzeugspezifischen Daten mit den Daten übereinstimmen
müssen, welche in dem zentralen Rechner für das
Kraftfahrzeug gespeichert sind. Die vorgegebene Mindestanzahl der übereinstimmenden
Daten kann dabei flexibel festgelegt werden, abhängig von
der gewünschten Sicherheit.
-
Wenn
in diesem Zusammenhang davon die Rede ist, dass „in dem
zentralen Rechner” für das Kraftfahrzeug Daten
gespeichert sind, so umfasst dies auch die Speicherung der Informationen
auf einem anderen Rechner, z. B. in einer Datenbank, die mit dem
zentralen Rechner in Kommunikationsverbindung steht und durch den
zentralen Rechner auslesbar ist.
-
Gemäß einer
weiteren Ausgestaltung wird zur Absicherung des Verbindungsaufbaus
ein Challenge-Response-Verfahren verwendet. Dies weist den Vorteil
auf, dass die dazu notwendigen Algorithmen aus dem Bereich der Sicherheitstechnik
gut bekannt, bewährt und erprobt sind.
-
Insbesondere
wird ein symmetrisches Challenge-Response-Verfahren mit einem gemeinsamen Schlüssel
für den zentralen Rechner und den Rechner des Kraftfahrzeugs
verwendet. Dieses Verfahren weist den Vorteil auf, dass die Verteilung
des gemeinsamen Schlüssels auf einfache Weise möglich
ist. Insbesondere kann hierbei vorgesehen sein, dass ein identischer
gemeinsamer Schlüssel für eine Mehrzahl an Kraftfahrzeugen
verwendet wird, was die Schlüsselerzeugung und -verteilung
weiter vereinfacht.
-
Zur
Erhöhung der Sicherheit gegenüber Kompromittierung
des gemeinsamen Schlüssels kann vorgesehen sein, dass ein
gemeinsamer Schlüssel lediglich für eine Gruppe
von Kraftfahrzeugen verwendet wird und für verschiedene
Gruppen von Kraftfahrzeugen unterschiedliche gemeinsame Schlüssel
vorgesehen sind. So kann beispielsweise der gemeinsame Schlüssel
in Abhängigkeit eines in dem jeweiligen Kraftfahrzeug verbauten
Zentral-Steuergeräts (ECU, Electronic Control Unit) gewählt
sein. Ebenso könnte in Abhängigkeit der Fahrgestellnummer
für einen bestimmten Nummernblock ein gemeinsamer Schlüssel
vergeben werden. Je kleiner die Gruppe von Kraftfahrzeugen ist,
für die ein gemeinsamer Schlüssel vorgesehen ist,
desto größer ist die Sicherheit gegenüber
Manipulationen.
-
In
einer anderen Ausgestaltung wird ein asymmetrisches Challenge-Response-Verfahren verwendet,
bei dem der zentrale Rechner und der Rechner des Kraftfahrzeugs
jeweils einen privaten und ein durch einen gemeinsamen Vertrauensanker ausgestelltes
Zertifikat, das einen signierten öffentlichen Schlüssel
umfasst, verwenden. Auf diese Weise ist eine erhöhte Sicherheit
gegenüber Manipulationen sichergestellt, da für
jedes Kraftfahrzeug ein individueller privater Schlüssel
vorgesehen ist.
-
Insbesondere
sieht das erfindungsgemäße Verfahren vor, dass
durch den Rechner des Kraftfahrzeugs eine durch den zentralen Rechner
des Rechnernetzwerks an den Rechner des Kraftfahrzeugs übertragene
Challenge mit dem privaten Schlüssel unter Einbeziehung
des zumindest einen fahrzeugspezifischen Datums signiert wird. Hierdurch
ist auf einfache Weise die Überprüfung der Identität
des die signierte Challenge (Response) sendenden Rechners und damit
des Kraftfahrzeugs möglich. Darüber hinaus sind
auf Basis des Zertifikats weitere Prüfungen möglich,
je nachdem welche Verknüpfung man zwischen Fahrzeugidentität
und Zertifikat wählt, oder ob man eine Laufzeitbegrenzung
oder auch eine Sperrliste verwendet.
-
In
einer weiteren Ausgestaltung ist vorgesehen, dass das Challenge-Response-Verfahren
unter Zwischenschaltung eines weiteren Rechners und eines tragbaren
Datenspeichers durchgeführt wird für den Fall,
dass zwischen dem Rechner des Kraftfahrzeugs und dem zentralen Rechner
des Rechnernetzwerks keine unmittelbare Kommunikationsverbindung
besteht oder herstellbar ist. Eine derartige Anwendung ist beispielsweise
dann zweckmäßig, wenn die Software eines bestimmten
Steuergeräts des Kraftfahrzeugs aktualisiert werden soll.
Der Download der zur Verfügung gestellten aktualisierten
Software kann für den Nutzer auf einfachere und schnellere
Weise über den heimischen PC abgerufen und auf dem tragbaren
Datenspeicher gespeichert werden. In diesem Falle ist es notwendig,
die Identifikation und/oder Authentisierung zumindest des Kraftfahrzeugs
gegenüber dem Rechner des Rechnernetzwerks an die beschriebene
Nutzungssituation anzupassen und hierbei den zwischengeschalteten weiteren
Rechner sowie den tragbaren Datenspeicher zu berücksichtigen.
Insbesondere wird dies dadurch bewerkstelligt, dass der weitere
Rechner bei der Identifikation und/oder der Authentisierung einen Stellvertreter
des Rechners des Fahrzeugs sowie einen Stellvertreter des zentralen
Rechners darstellt. Für eine vollständige Identifikation
und/oder Authentisierung ist es daher notwendig, dass der Datenspeicher
zumindest einmal in Kommunikationsverbindung mit dem zentralen Rechner
des Rechnernetzwerks und einmal mit dem Rechner des Kraftfahrzeugs
in Verbindung steht. Hierbei kann insbesondere vorgesehen sein,
dass im Rahmen der Absicherung des Verbindungsaufbaus nur die Authentizität des
zentralen Rechners überprüft wird.
-
Das
erfindungsgemäße Verfahren ermöglicht
darüber hinaus auf einfache Weise die Einbindung eines
Auditing-Verfahrens, bei dem beispielsweise überprüft
wird, wie häufig der Verbindungsaufbau in einer vorgegebenen
Zeitspanne fehlschlägt. Auf diese Weise kann beispielsweise
auf einen Manipulationsversuch geschlossen werden, wenn innerhalb
eines begrenzten Zeitraums eine hohe Anzahl an versuchten Verbindungsaufbauten
registriert wurde. Ferner ermöglicht es diese Ausgestaltung,
z. B. gestohlene Kraftfahrzeuge von der Nutzung von von dem Rechnernetzwerk
angebotenen Diensten auszuschließen.
-
Es
kann ferner vorgesehen sein, dass bei Überschreitung einer
vorgegebenen Anzahl von fehlgeschlagenen Verbindungsaufbauten ein
weiterer Verbindungsaufbau zwischen dem Rechner des Kraftfahrzeugs
und dem zentralen Rechner des Rechnernetzwerks verhindert wird.
-
Die
Einbindung eines Auditing-Verfahrens in den abgesicherten Verbindungsaufbau
einer Kommunikationsverbindung lässt sich bei den bislang
aus dem Stand der Technik bekannten Verfahren zum Verbindungsaufbau
nicht oder nur mit Einschränkungen realisieren. Das erfindungsgemäße
Vorgehen weist darüber hinaus den Vorteil auf, dass unterschiedliche
Sicherheitsniveaus von Applikationen möglich sind. Die
Verfahren sind im Hinblick auf ihre Sicherheit unterschiedlich stark
und es können verschiedene Authentisie rungs-Niveaus oder
-Levels an die unterschiedlichen Applikationen gebunden und durchgesetzt
werden. Es ist ferner möglich, eine bestehende Session
aufzuwerten, wenn das Kraftfahrzeug zuvor mit einem geringeren Sicherheitsniveau an
dem zentralen Rechner des Rechnernetzwerks angemeldet ist. In einem
nachfolgenden Schritt kann bei Zugriff auf eine höher geschützte
Applikation eine Aufwertung erfolgen.
-
Die
Erfindung schlägt ferner einen Rechner eines Kraftfahrzeugs
vor, der zur Durchführung des beschriebenen Verfahrens
ausgebildet ist.
-
Ferner
schafft die Erfindung ein Kommunikationsnetzwerk, das zumindest
einen Rechner eines Kraftfahrzeugs und einen zentralen Rechner eines Rechnernetzwerks
umfasst, welche zur Durchführung des beschriebenen Verfahrens
ausgebildet sind.
-
Die
Erfindung wird nachfolgend näher anhand von Ausführungsbeispielen
in der Zeichnung beschrieben. Es zeigen:
-
1 den
schematischen Ablauf eines abgesicherten Verbindungsaufbaus einer
Kommunikationsverbindung gemäß einer ersten Ausführungsvariante,
-
2 den
schematischen Ablauf eines abgesicherten Verbindungsaufbaus einer
Kommunikationsverbindung gemäß einer zweiten Ausführungsvariante,
-
3 den
schematischen Ablauf eines abgesicherten Verbindungsaufbaus einer
Kommunikationsverbindung gemäß einer dritten Ausführungsvariante,
und
-
4 den
schematischen Ablauf einer Plausibilitätsprüfung
während eines abgesicherten Verbindungsaufbaus gemäß einer
der Varianten der Erfindung.
-
Das
erfindungsgemäße Verfahren ermöglicht
eine Identifikation und Authentisierung von Kraftfahrzeugen als
vollständige Entität gegenüber einem Rechnernetzwerk,
beispielsweise des Herstellers des Kraftfahrzeugs oder eines Dienstleisters
des Herstellers. Insbesondere schlägt das erfindungsgemäße
Verfahren die Absicherung des Verbindungsaufbaus eines Rechners
des Kraftfahrzeugs beim Zugriff auf Applikationen in dem Rechnernetzwerk vor.
Die Absicherung des Verbindungsaufbaus erfolgt hierbei rechnergestützt ohne
einen manuellen Eingriff oder eine manuelle Eingabe eines Nutzers
des Kraftfahrzeugs. Typischerweise wird der Verbindungsaufbau hierbei
durch den Rechner des Kraftfahrzeugs initiiert. Denkbar ist jedoch
auch, dass der Verbindungsaufbau durch den zentralen Rechner des
Rechnernetzwerkes gestartet wird.
-
Durch
den gesicherten Verbindungsaufbau der Kommunikationsverbindung verhält
sich der Rechner des Kraftfahrzeugs aus Sicht des Rechnernetzwerks
wie eine Komponente des Rechnernetzwerks, so dass bei erfolgreichem
Verbindungsaufbau eine Kommunikation unter Verwendung herkömmlicher
Absicherungsverfahren erfolgen kann. Insbesondere wird die Nutzung
des abgesicherten Verbindungsaufbaus auf der Ebene von Applikationen
ermöglicht, und damit insbesondere des Session Managements
oder des Single-Sign Ons.
-
Die
Absicherung des Verbindungsaufbaus umfasst die Überprüfung
der Identität und/oder die Authentisierung des Kraftfahrzeugs
und/oder des Fahrers des Kraftfahrzeugs durch den zentralen Rechner über
eine drahtlose Kommunikationsverbindung. Insbesondere bedient sich
das erfindungsgemäße Verfahren hierzu einer Challenge-Response-Authentisierung,
welche in verschiedenen Ausprägungen zur Anwendung gelangen
kann.
-
1 zeigt
in einer schematischen Darstellung den Ablauf eines gesicherten
Verbindungsaufbaus einer Kommunikationsverbindung mittels einer symmetrischen
Challenge-Response-Authentisierung unter Verwendung eines gemeinsamen
Schlüssels. Dargestellt sind hierbei die beim Verbindungsaufbau
beteiligten Komponenten. Mit 10 sind Komponenten des Kraftfahrzeugs
(„Vehicle”) gekennzeichnet. Das Bezugszeichen 20 kennzeichnet
eine drahtlose Datenübertragungsstrecke, welche in der
Figur auch als „Transmission” gekennzeichnet ist.
Mit 30 ist ein Rechnernetzwerk („BusinessIT”)
gekennzeichnet, wobei das Rechnernetzwerk durch den Hersteller des
Kraftfahrzeugs und/oder einen Dienstleister des Herstellers verwaltet
werden kann.
-
Das
Kraftfahrzeug 10 umfasst einen Rechner 11, auf
welchem eine oder mehrere Applikationen 12 („Application”)
ablaufen. Der Rechner 11 umfasst eine oder steht mit einer
Kryptographieeinheit 13 („Crypto-API”)
kommunikativ in Verbindung. Die Kryptographieeinheit 13 ist
für die Durchführung einer rein kryptographischen
Funktion zuständig.
-
Das
Rechnernetzwerk 30 ist stellvertretend durch einen zentralen
Rechner 31 repräsentiert, welcher eine Kommunikationseinheit 32 („Communication”)
sowie eine Kryptographieeinheit 33 („Security” und „CryptModule”)
umfasst. Die Kryptographieeinheit 33 muss nicht zwingend
in dem zentralen Rechner 31 ausgebildet sein, sondern kann
auch ein mit dem zentralen Rechner kommunikativ verbundener eigenständiger
Rechner sein. Entsprechend der Kryptographieeinheit 13 des
Kraftfahrzeugs 10 ist die Kryptographieeinheit 33 des
zentralen Rechners 31 auf Seiten des Rechnernetzwerkes
für die Durchführung einer rein kryptographischen
Funktion zuständig. Außerdem kann über
diese Komponente ein Hardware-gesicherter Schlüsselspeicher
angeschlossen werden.
-
Die
Kryptographieeinheiten 13 und 33 können
darüber hinaus nach dem erfolgreichen Verbindungsaufbau
auch für die Absicherung der Datenübertragung
zwischen dem Rechner 11 und dem zentralen Rechner 31 verwendet
werden.
-
In
dem in 1 dargestellten Ablauf wird ein symmetrisches
Challenge-Response-Verfahren durchgeführt, das eine Signatur
der Challenge mit einem symmetrischen Schlüssel durchführt.
Dieser kann prinzipiell für eine Vielzahl von Fahrzeugen oder
sogar für alle Fahrzeuge (d. h. für alle Rechner der
Fahrzeuge) gleich sein oder aber in Gruppen unterteilt werden. Die
Unterteilung in Gruppen kann beispielsweise in Abhängigkeit
eines verbauten zentralen Steuergeräts realisiert sein.
Dabei verwenden Fahrzeuge mit einem bestimmten zentralen Steuergerät
den gleichen Schlüssel. Fahrzeuge mit einem anderen, davon
abweichenden Steuergerät verwenden einen anderen, jedoch
ebenfalls gleichen Schlüssel, usw. Die Unterteilung in
Gruppen dient der sog. Schlüsselauffächerung.
-
Das
Verfahren erlaubt eine gegenseitige Ende-zu-Ende-Authentisierung,
wobei als fahrzeugspezifisches Datum insbesondere eine Fahrgestellnummer
(VIN = Vehicle Identification Number) als fahrzeugindividuelles
Merkmal in die Challenge bzw. Response einbezogen wird. Die zwischen
dem Rechner 11 und dem zentralen Rechner 31 ausgetauschten Daten
basieren insbesondere auf einer XML-Struktur. XML steht für
Extendable Markup Language und ist ein im Bereich von Rechnernetzwerken
häufig benutzter Standard. Wie eingangs bereits erläutert, werden
die zwischen den Rechner 11 und dem zentralen Rechner 31 ausgetauschten
Nachrichten auf drahtlose Weise über die Datenübertragungsstrecke 20 übertragen.
Die Datenübertragungsstrecke kann gemäß dem Standard
WLAN, GSM, UMTS und dergleichen, ausgebildet sein. Zweckmäßigerweise
werden die Nachrichten auf dem IP-Protokoll basierend übertragen.
-
Der
Ablauf zur wechselseitigen Identifikation und Authentisierung umfasst
die folgenden Schritte:
- 1. Der Anstoß zur
Durchführung eines gesicherten Verbindungsaufbaus erfolgt
durch die Applikation 12. Beispielsweise kann dieser durch
einen Nutzer des Kraftfahrzeugs ausgelöst sein, der in dem
Kraftfahrzeug eine bestimmte Applikation, welche von dem Rechnernetzwerk
bereitgestellt wird, starten möchte. In einem ersten Schritt
wird durch die Applikation 12 ein Triggersignal („Trigger”)
an die Kryptographieeinheit 13 übertragen, welche
daraufhin eine Zufallszahl generiert und eine Challenge („Fahrzeug-Challenge”)
mit der Fahrzeugidentifikationsnummer VIN als Identifikationsmerkmal über
die Datenübertragungsstrecke 20 an den zentralen
Rechner 31 überträgt. Neben der Zufallszahl
RAND_FZG und der Fahrzeugidentifikationsnummer VIN wird eine Nachrichten-ID
(„MSG-ID”) zusammen mit einem Authentisierungs-Modus
(„Auth-Mode”) an den zentralen Rechner 31 übertragen.
Wie erläutert, erfolgt die Übertragung basierend
auf einer XML-Struktur. Die Nachricht (d. h. die Challenge) ist
in der Figur als „auth_server_chall” gekennzeichnet.
Die diese Nachricht entgegennehmende Kommunikationseinheit 32 überträgt
diese an die Kryptographieeinheit 33. Die Fahrzeug- oder Client-Challenge
wird durch die Kryptographieeinheit 33 durch Aufruf einer
Funktion „sign” signiert.
- 2. Mit Hilfe einer durch die Kryptographieeinheit 33 erzeugten
Zufallszahl (RAND_ASrv:=genRND()) wird eine Server-Challenge erzeugt.
Diese wird zusammen mit der Signatur der Client-Challenge („Fahrzeug-Response”) über
die Datenübertragungsstrecke 20 an den Rechner 11 des
Kraftfahrzeugs 10 übertragen. Die von dem zentralen 31 an
den Rechner 11 übertragene Nachricht „auth_server_resp_chall” im
XML-Format umfasst die folgenden Parameter: MSG-ID, Auth-Mode, VIN,
SIG ASrv sowie RAND_ASrv. Der Rechner 11 prüft
mit seinem geheimen Schlüssel, ob die Client-Challenge
korrekt signiert wurde. Ist dies nicht der Fall, wird die Kommunikationsverbindung
von dem Rechner 11 bereits an dieser Stelle beendet.
- 3. Der Rechner 11 signiert nun mittels des geheimen
Schlüssels die Server-Challenge (SIG_FZG:=sign(K_L4,RAND_ASrv))
und überträgt das Ergebnis an den zentralen Rechner 31. Die
Nachricht ist in 1 mit „auth_client_resp” gekennzeichnet.
Mittels der Prüffunktion „verify”, die
durch die Kryptographieeinheit 13 angeboten wird, wird
durch den Rechner 11 die Richtigkeit der von dem zentralen
Rechner 31 übermittelten Signatur überprüft.
In entsprechender Weise prüft der zentrale Rechner 31 mittels
der Prüffunktion „verify” die Richtigkeit
der von dem Rechner 11 des Kraftfahrzeugs 10 übermittelten
Signatur der Server-Challenge.
- 4. Nach erfolgreicher Prüfung, d. h. Authentisierung,
informiert der zentrale Rechner 31 den Rechner 11 des
Kraftfahrzeugs 10 im vierten Protokollschritt über
die erfolgreiche Authentisierung. Diese Nachricht ist mit „auth_client_ok” gekennzeichnet.
-
Damit
ist die erfolgreiche wechselseitige Überprüfung
der Identität und Authentisierung abgeschlossen, woraufhin
mit der eigentlichen Datenübertragung begonnen werden kann.
Diese kann auf beliebige Weise erfolgen. Insbesondere kann die Übertragung
gesichert vorgenommen werden.
-
2 zeigt
den Ablauf des erfindungsgemäßen gesicherten Verbindungsaufbaus
mit einem asymmetrischen Challenge-Response-Verfahren. Dabei werden
fahrzeugindividuelle Zertifikate eingesetzt. Die Ausgangsbasis stellt
wiederum das in 1 beschriebene Protokoll dar.
Die Sicherheit des Verbindungsaufbaus ist jedoch erhöht,
da sowohl der Rechner 11 des Kraftfahrzeugs 10 („Vehicle”)
als auch der zentrale Rechner 31 des Rechnernetzwerks 30 („OEM
Business IT”) seinen eigenen Schlüssel bzw. eigenes
Schlüsselpaar erhalten. Es wird ein asymmetrisches, kryptographisches
Verfahren zur Signatur und Signaturprüfung eingesetzt.
Dies bedeutet, jedes Schlüsselpaar umfasst einen privaten Schlüssel
sowie ein Zertifikat, das einen signierten öffentlichen
Schlüssel enthält. Die Zertifikate des Rechners 11 sowie
des zentralen Rechners 31 werden durch einen gemeinsamen
Vertrauensanker, z. B. unter Verwaltung des Kraftfahrzeugherstellers, ausgestellt.
Mit anderen Worten wird in dem Verfahren eine Public-Key-Infrastruktur
eingesetzt.
-
Der
Ablauf zur wechselseitigen Identifikation und Authentisierung umfasst
die folgenden Schritte:
- 1. Der gesicherte Verbindungsaufbau
wird wiederum durch die Applikation 12 (z. B. aufgrund
einer Aktion des Nutzers des Kraftfahrzeugs) initiiert. Hierzu wird
durch die Kryptographieeinheit 13 eine Zufallszahl RAND_CM
erzeugt. In einer Client-Challenge („Fzg-Challenge”)
wird diese zusammen mit der Fahrzeugidentifikationsnummer VIN als
Identifikationsmerkmal in einer Nachricht „auth_server_chall” an
den zentralen Rechner 31 übertragen. Die Client-Challenge
wird durch die Kryptographieeinheit 31 durch Aufruf der
Funktion „sign” signiert. Dabei wird der asymmetrische Schlüsselname
als Parameter dieser Funktion übergeben. Gleichzeitig wird
eine Zufallszahl „RAND_ASrv” generiert.
- 2. Eine durch die Kryptographieeinheit 33 erzeugte
Server-Challenge („ASrv-Challenge”) und die Signatur
der Client-Challenge („Fzg-Response”) werden an
das Kraftfahrzeug 10 bzw. den Rechner 11 übermittelt.
Der Rechner 11 überprüft das übermittelte
Zertifikat mittels des gespeicherten, öffentlichen Schlüssels
auf Echtheit und verwendet den im Zertifikat enthaltenen öffentlichen Schlüssel
des zentralen Rechners 31 zur Prüfung, ob die
Client-Challenge korrekt signiert wurde. Im Fehlerfall wird die
Kommunikationsverbindung durch den Rechner 11 des Kraftfahrzeugs 10 beendet.
- 3. Der Rechner 11 signiert mit seinem privaten Schlüssel
die Server-Challenge („ASrv-Challenge”), wobei
in die Signatur die Fahrzeugidentifikationsnummer VIN einbezogen
wird. Diese Server-Response („ASrv-Response”)
wird zusammen mit dem Zertifikat des Rechners 11 an den zentralen
Rechner 31 übertragen. In der Kryptographieeinheit 33 des
zentralen Rechners 31 wird die Richtigkeit der von dem
Rechner 11 übermittelten Signatur der Server-Challenge
zusammen mit der Fahrzeugidentifikationsnummer VIN überprüft.
Gleichzeitig erfolgt eine Prüfung, ob dessen Zertifikat
noch gültig ist. Die Zertifikatsprüfung erfolgt
in einer Zertifikatskettenprüfung mit dem Aussteller-Zertifikat.
Ebenso wird eine Prüfung des übermittelten Zertifikats
gegen eine in dem zentralen Rechner 31 oder eine mit diesem
verbundenen Speicher enthaltenen Zertifikatsbauliste durchgeführt.
In der Zertifikatsbauliste sind solche Zertifikate enthalten, welche
einem für ein Kraftfahrzeug be stimmten Rechner während
der Fertigung zugeordnet wurden. Die Rechner kamen beispielsweise
aufgrund eines Defekts jedoch nicht zum Einsatz. Damit sind die
diesen Rechnern zugewiesenen Zertifikate ungültig und werden
in der Zertifikatsbauliste erfasst.
- 4. Nach erfolgreicher Prüfung, d. h. Authentisierung,
informiert der zentrale Rechner 31 (Finalization) den Rechner 11 des
Kraftfahrzeugs 10 über die erfolgreiche Authentisierung.
Dies erfolgt vermittels der Nachricht „auth_client_ok”.
-
Das
im Zusammenhang mit 2 beschriebene Verfahren kann
auch für die Authentisierung des Fahrers verwendet werden.
Zur Authentisierung des Fahrers werden bislang Benutzername und passwortbasierte
Verfahren eingesetzt, die jedoch einen verhältnismäßig
geringen Schutz gegenüber Manipulation bieten. Das in Zusammenhang
mit 2 beschriebene Verfahren bzw. Protokoll kann für
die Authentisierung des Fahrers beibehalten werden. Allerdings werden
Zertifikate für die Fahrer bzw. Endkunden anstatt die Kraftfahrzeuge
ausgestellt. Das Zertifikat kann über verschiedene Trägermedien,
wie z. B. einen Schlüssel des Kraftfahrzeugs, ein Mobilfunkendgerät,
eine Kundenkarte oder dergleichen, an den Fahrer bzw. Kunden ausgegeben
werden. Das Zertifikat wird dann in dem Kraftfahrzeug aus dem Trägermedium
ausgelesen. Hierzu ist eine entsprechend dem Trägermedium
ausgebildete Lesekomponente in dem Kraftfahrzeug vorgesehen.
-
3 zeigt
einen weiteren Anwendungsfall, in dem das Kraftfahrzeug 10 nicht
direkt (online) mit dem zentralen Rechner 31 des Rechnernetzwerks 30 („OEM
Backend”) in Verbindung steht. Die Durchführung
des gesicherten Verbindungsaufbaus erfolgt hierbei unter Zwischenschaltung
eines weiteren Rechners 40 und eines tragbaren Datenspeichers 41,
wobei der weitere Rechner 40 bzw. Datenspeicher 41 bei
der Überprüfung der Identität und/oder der
Authentisierung einen Stellvertreter des Rechners des Kraftfahrzeugs 10 und
einen Stellvertreter des zentralen Rechners 31 des Rechnernetzwerks 30 darstellen.
Dieser Anwendungsfall dient dem Zweck, dass der Nutzer 42 des
Kraftfahrzeugs z. B. Daten (ein Softwareupdate) über den
Datenspeicher, z. B. einen USB-Stick, einbringt. Dabei kann es in
bestimmten Anwendungsszenarien erforderlich sein, die Authentizität
des zentralen Rechners gegenüber dem Kraftfahrzeug, und
umgekehrt, abzusichern. Der weitere Rechner 40, auf dem
beispielsweise ein Webportal zur Verfügung gestellt wird,
stellt die Schnittstelle zu dem zentralen Rechner 31 des
Rechnernetzwerks 30 dar. Der Datenspeicher 41 stellt
die Schnittstelle zu dem Kraftfahrzeug 10 dar.
-
Der
Ablauf zur wechselseitigen Identifikation und Authentisierung umfasst
die folgenden Schritte:
- 1. Der Nutzer 42 verbindet
den Datenspeicher mit dem weiteren Rechner 41 und meldet
sich an einem Portal an. Über den weiteren Rechner 40 wird
eine Challenge („PC-Challenge”) unter Verwendung
einer Zufallszahl „RAND_PC” erzeugt. Die Challenge
(Nachricht „auth_server_resp_chall”) wird an den
zentralen Rechner 31 des Rechnernetzwerks übertragen.
- 2. In dem zentralen Rechner 31 wird eine Challenge
(„ASrv-Challenge”) unter Verwendung einer durch
die Kryptographieeinheit 33 erzeugten Zufallszahl „RAND_ASrv” erzeugt
und an den weiteren Rechner 41 übertragen. Gleichzeitig
wird eine Response („PC-Response”) an den weiteren Rechner 41 übertragen.
Die Übertragung der durch den zentralen Rechner 31 erzeugten
Challenge und Response erfolgt in der gemeinsamen Nachricht „auth_server_resp_chall”.
Die in der Nachricht enthaltenen Informationen werden auf den Datenspeicher 41 geschrieben.
- 3. Der Nutzer 42 kann nun den Datenspeicher 41 mit
dem Rechner 11 des Kraftfahrzeugs 10 verbinden.
Durch den Rechner 11 wird die Response („PC-Response”) überprüft.
Gegebenenfalls kann an dieser Stelle ein Abbruch des Verbindungsaufbaus
erfolgen, wenn lediglich die Überprüfung der Authentizität
des zentralen Rechners 31 des Rechnernetzwerks 30 erforderlich
ist. Soll eine gegenseitige Identifikation und Authentisierung erfolgen,
so wird durch den Rechner 11 des Kraftfahrzeugs 10 eine
Response („ASrv-Response”) für die von
dem zentralen Rechner 31 erzeugte Challenge erzeugt und
auf den Datenspeicher 41 geschrieben.
- 4. Nach einer Verbindung des Datenspeichers 42 mit
dem weiteren Rechner 41 und einer erneuten Anmeldung des
Nutzers am Portal kann die Response („ASrv-Response”)
an den zentralen Rechner 31 übertragen und überprüft
werden. Das in dem beschriebenen Anwendungsszenario beschriebene
Challenge-Response-Verfahren kann wahlweise als symmetrisches oder
asymmetrisches Challenge-Response-Verfahren ausgebildet sein.
-
Die
beschriebenen Verfahren können um eine Plausibilitätsprüfung
ergänzt sein. Dies ist beispielsweise dann sinnvoll, wenn
bei dem symmetrischen Challenge-Response-Verfahren der übergreifende
Schlüssel kompromittiert ist oder wenn das Verfahren aus
prinzipiellen Erwägungen ergänzt werden soll.
Die Plausibilitätsprüfung erfolgt anhand weitgehend
statischer Merkmale des Kraftfahrzeugs. Diese werden in einer XML-Nachricht
durch den Rechner 11 des Kraftfahrzeugs an den zentralen Rechner 31 des
Rechnernetzwerks 30 in der Nachricht „auth_server_chall” übertragen.
Der zentrale Rechner 31 verfügt über
fahrzeugspezifische Informationen, die er entweder in einem Speicher
vorhält oder aber aus einer mit dem zentralen Rechner verbundenen
Datenbank ermitteln kann. Durch den zentralen Rechner 31 erfolgt
dann ein Vergleich der in der Nachricht übertragenen statischen
Fahrzeuginformationen mit den gespeicherten Informationen. Geeignete
statische Merkmale können beispielsweise neben der Fahrgestellnummer
VIN die Fahrzeugfarbe, die Art der Sitzpolsterung, das Fahrzeugmodell,
die Karosserieform und dergleichen, sein. Dies ist schematisch in 4 dargestellt.
Die genannten Informationen werden zweckmäßigerweise
in die in 1 bis 3 beschriebenen
Verfahren in die Challenge des Rechners 11 des Kraftfahrzeugs
integriert. Die Plausibilitätsprüfung kann beispielsweise dahingehend
ausgestaltet sein, dass überprüft wird, ob zwei
von vier Merkmalen, oder drei von fünf Merkmalen, oder
vier von fünf Merkmalen oder alle Merkmale erfüllt
sind.
-
Das
er indungsgemäße Verfahren bietet eine wesentlich
bessere Absicherung des Zugriffs des Kraftfahrzeugs bzw. des Kunden
des Kraftfahrzeugs auf Applikationen, die der Fahrzeughersteller
oder ein Dienstleistungspartner in einer Rechnerinfrastruktur anbieten
können. Da diese Funktionen kostenpflichtig sein können
oder anderweitigen Schutzbedarf aufweisen, lässt sich auf
diese Weise die Identität des Fahrzeugs bzw. Fahrers zweifelsfrei feststellen.
Somit wird die Abrechnung von Diensten ermöglicht. Darüber
hinaus ist der Schutz kundenbezogener Daten im Online-Zugriff gewährleistet.
Dies gilt auch bei einer Datenerhebung bei Gewährleistungsfällen
oder sonstigen beweispflichtigen Aktivitäten. Darüber
hinaus gewährleistet das erfindungsgemäße
Verfahren auch die Au thentizität des Kraftfahrzeugs bei
der Ferndiagnose und Fahrzeugprogrammierung. Bei diesen Anwendungsszenarien
ist die Gefahr manipulierter Daten oder Software besonders groß.
Die Erfindung stellt eine Möglichkeit bereit, einen Missbrauch
zu verhindern.
-
- 10
- Kraftfahrzeug
(„Vehicle”)
- 11
- Rechner
des Kraftfahrzeugs
- 12
- Applikation
(„Applikation”)
- 12'
- Applikation
auf Datenspeicher („USB-Stick/Applikation”)
- 13
- Kryptographieeinheit
(Crypto-API”)
- 14
- Zentralsteuergerät
(„ECU”)
- 20
- Datenübertragungsstrecke
(„Transmission”)
- 30
- Rechnernetzwerk
(„BusinessIT”)
- 31
- zentraler
Rechner („Backend”)
- 32
- Kommunikationseinheit
(„Communication”)
- 33
- Kryptographieeinheit
(„Security” und „CryptModule”)
- 40
- weiterer
Rechner
- 41
- Datenspeicher
- 42
- Nutzer
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste
der vom Anmelder aufgeführten Dokumente wurde automatisiert
erzeugt und ist ausschließlich zur besseren Information
des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen
Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt
keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Nicht-Patentliteratur
-
- - WLAN (Wireless
Local Area Network) [0002]
- - GSM (Global System for Mobile Communications) [0002]
- - UMTS (Universal Mobile Telecommunications System) [0002]
- - Standard ISO 9798 von 1998 [0003]
- - Standards ISO 15764 [0004]
- - Standard WLAN, GSM, UMTS [0044]