DE10008974A1 - Signaturverfahren - Google Patents
SignaturverfahrenInfo
- Publication number
- DE10008974A1 DE10008974A1 DE10008974A DE10008974A DE10008974A1 DE 10008974 A1 DE10008974 A1 DE 10008974A1 DE 10008974 A DE10008974 A DE 10008974A DE 10008974 A DE10008974 A DE 10008974A DE 10008974 A1 DE10008974 A1 DE 10008974A1
- Authority
- DE
- Germany
- Prior art keywords
- control unit
- software
- vehicle
- key
- stored
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B19/00—Programme-control systems
- G05B19/02—Programme-control systems electric
- G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
- G05B19/042—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
- G05B19/0426—Programming the control sequence
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
- G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
- H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B2219/00—Program-control systems
- G05B2219/20—Pc systems
- G05B2219/23—Pc programming
- G05B2219/23305—Transfer program into prom with passwords
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B2219/00—Program-control systems
- G05B2219/20—Pc systems
- G05B2219/24—Pc safety
- G05B2219/24155—Load, enter program if device acknowledges received password, security signal
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B2219/00—Program-control systems
- G05B2219/20—Pc systems
- G05B2219/24—Pc safety
- G05B2219/24159—Several levels of security, passwords
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B2219/00—Program-control systems
- G05B2219/20—Pc systems
- G05B2219/24—Pc safety
- G05B2219/24167—Encryption, password, user access privileges
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B2219/00—Program-control systems
- G05B2219/20—Pc systems
- G05B2219/26—Pc applications
- G05B2219/2637—Vehicle, car, auto, wheelchair
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/84—Vehicles
Abstract
Die Erfindung betrifft ein Verfahren zur Sicherstellung der Datenintegrität einer Software für ein Steuergerät eines Kraftfahrzeugs, in dem in einem Speicher des Steuergeräts eine das Steuergerät in seiner Wirkungsweise beeinflussende Software speicherbar ist. DOLLAR A Es wird vorgeschlagen, ein Schlüsselpaar zum Ver- und Entschlüsseln von elektronischen Daten bereitzustellen, den ersten Schlüssel in einem oder für ein Steuergerät in dem Kraftfahrzeug zu hinterlegen mit dem zweiten Schlüssel eine einzuspielende Software zu signieren, die signierte Software in den Speicher des Steuergerätes einzuspielen und die Signatur der Software mittels dem in oder für das Steuergerät hinterlegten Schlüssel zu überprüfen und dann zu akzeptieren, wenn die Überprüfung mit positivem Ergebnis verläuft.
Description
Die Erfindung betrifft ein Verfahren zur Sicherstellung der Datenintegrität einer
Software für ein Steuergerät eines Kraftfahrzeugs.
Mit dem zunehmenden Anteil der Elektronik und der Kommunikationsmöglichkeiten
im und mit einem Fahrzeug wachsen auch die Anforderungen, welche an die Si
cherheit gestellt werden müssen.
In den verschiedensten Bereichen des Fahrzeugs werden Microcontroller zur
Steuerung eingesetzt. Diese Steuergeräte sind heutzutage oft über ein Bussystem
miteinander verbunden, und es gibt meist Möglichkeiten (z. B. Diagnoseverbindung),
von außen auf diesen Bus zuzugreifen und mit den einzelnen Steuergeräten zu
kommunizieren.
Die Funktionsweise der Steuergeräte wird durch Softwareprogramme bestimmt.
Bisher ist die Software, die in einem Steuergerät (auch: Controller) eingesetzt wird,
meist in einem nicht programmierbaren Speicher abgelegt (z. B. bei maskenpro
grammierte Mikroprozessoren). Dadurch ist eine Manipulation der Software nicht
ohne weiteres zu realisieren. Beispielsweise kann der komplette Austausch eines
Speicherbausteins gegen einen anderen Speicherbaustein erkannt und entspre
chend darauf reagiert werden.
Durch den zukünftigen Einsatz von programmierbaren, insbesondere sogenannten
flashprogrammierbaren Steuergeräten im Fahrzeug wird die Gefahr jedoch größer,
daß unbefugte Manipulationen an der Software und somit an der Arbeitsweise der
Steuergeräte durchgeführt werden. So könnte der Austausch von Software seitens
nicht autorisierter Personen einfach durch Neuprogrammierung mit geringem Auf
wand vollzogen werden.
Aus Sicherheitsgründen und zur Erfüllung von gesetzlichen Anforderungen müssen
jedoch Maßnahmen ergriffen werden, die entweder eine Veränderung von Origi
nalsoftware verhindern oder eine solche Änderung nur autorisierten Personen zu
gestehen.
Im übrigen könnte es sich zukünftig als vorteilhaft erweisen, ein Gleichteile-Konzept
zu Verfolgen, wobei bei unterschiedlichen Modellen gleiche Hardware verwendet
wird. Der Unterschied in der Funktionsweise liegt dann nur noch in der Software.
Bei diesem Konzept besteht freilich die Notwendigkeit, daß eine bestimmte Soft
ware nur auf einem individuellen Fahrzeug lauffähig ist und nicht einfach kopierbar
sein darf.
Aus dem Stand der Technik sind eine Vielzahl von Authentifizierungsverfahren und
-vorrichtungen bekannt.
So ist in der US 5,844,986 ein Verfahren beschrieben, welches zur Vermeidung
eines nicht erlaubten Eingriffs in ein BIOS-Systems eines PC verwendet wird. Ein
kryptographischer Coprozessor, der einen BIOS-Speicher enthält, führt basierend
auf einem sogenanten Publik-Key-Verfahren mit einem öffentlichen und einem ge
heimen Schlüssel eine Authentifizierung und Überprüfung einer BIOS-Änderung
durch. Dabei erfolgt die Überprüfung durch eine Prüfung einer in der einzuspielen
den Software eingebetteten digitalen Signatur.
Aus der EP 0 816 970 ist eine Vorrichtung zur Überprüfung einer Firmensoftware
bekannt. Diese Vorrichtung zur Authentifizierung eines Boot-PROM-Speichers um
faßt einen Speicherteil mit einem Mikro-Code. Ein Authentifizierungs-Sektor umfaßt
einen Hash-Generator, der Hash-Daten in Antwort auf die Ausführung des Mikro-
Codes erzeugt.
Mit den obigen Verfahren oder Vorrichtungen ist jedoch nicht unmittelbar die Über
prüfung einer in ein Steuergerät eines Kraftfahrzeuges einzuspielenden Software
möglich.
Aufgabe der vorliegenden Erfindung ist es, ein Verfahren zur Sicherstellung der
Einspielung einer authentischen Software in ein Steuergerät eines Kraftfahrzeugs
zur Verfügung zu stellen.
Die Aufgabe wird durch die Merkmale im Anspruch 1 gelöst.
Demgemäß wird zunächst ein Schlüsselpaar zum Ver- und Entschlüsseln von elek
tronischen Daten erzeugt. Unter Schlüssel versteht man hierbei allgemein Codier-
und/oder Decodierparameter, welche aus an sich bekannten kryptographischen
Algorithmen bekannt sind.
Vorliegend wird die Software mittels des ersten Schlüssels mit einer elektronischen
Unterschrift (Signatur) versehen. Zur Verifikation der Echtheit der Software ist in
dem oder für das Steuergerät, in dem diese Software eingespielt werden soll, ein
zugehöriger zweiter Schlüssel hinterlegt. Mit diesem zweiten Schlüssel kann die
elektronische Unterschrift der Software geprüft werden. Verläuft die Prüfung positiv,
so wird die Software akzeptiert und kann zur Steuerung des Steuergerätes heran
gezogen werden.
Als Verschlüsselung kann gemäß einer ersten Ausführungsform ein sogenanntes
symmetrisches Verfahren verwendet werden, bei dem beide Schlüssel identisch
sind. Eigentlich handelt es sich dabei also nur um einen Schlüssel, der an verschie
denen Stellen verwendet wird. Da aber immer mit Möglichkeiten gerechnet werden
muß, daß ein in einem Steuergerät hinterlegter Schlüssel bekannt wird, ist die Si
cherheitsstufe eines symmetrischen Verfahren nicht optimal. Ein solches Verfahren
kann nur daher dann eingesetzt werden, wenn nicht allzu sicherheitskritische Vorgänge
betroffen sind. Zur Erhöhung der Sicherheitsstufe kann ein zusätzlicher
Auslöseschutz in Form einer speziellen Hardware eingesetzt werden.
Gemäß einer weiteren bevorzugten Ausführungsform wird ein asymmetrisches Ver
schlüsselungsverfahren mit einem geheimen und einem öffentlichen Schlüssel ge
wählt. Dabei kann der öffentliche Schlüssel im oder für das Steuergerät hinterlegt
sein. Mit dem geheimen Schlüssel würde dann die Software signiert werden. Alter
nativ kann auch das Steuergerät oder das Fahrzeug selbst das asynchrone Schlüs
selpaar erzeugen und dann den geheimen Schlüssel in dem Steuergerät hinterle
gen. Der öffentliche Schlüssel müßte dann auslesbar sein, so daß mit ihm eine
Software signiert werden kann. Natürlich müßte bei der letzten Alternative sicherge
stellt werden, daß der geheime Schlüssel nicht auslesbar ist.
Bei den Verschlüsselungsalgorithmen mit einem geheimen und einem öffentlichen
Schlüssel handelt es sich um ein sogenanntes Public-Key-Verfahren, bei dem der
öffentliche Schlüssel öffentlich bekannt sein darf, wogegen der geheime Schlüssel
nur einer autorisierten Stelle, beispielsweise einem Trust-Center, bekannt ist. Sol
che kryptographischen Algorithmen sind z. B. Rivest, Shamir und Adleman (RSA-
Algorithmus), Data Encryption Algorithmus (DEA-Algorithmus) und dergleichen Al
gorithmen. Mit dem geheimen oder öffentlichen Schlüssel läßt sich - analog zur
handschriftlichen Unterschrift - eine digitale Signatur zu einem elektronischen Do
kument erzeugen. Nur der Besitzer des geheimen bzw. öffentlichen Schlüssels
kann eine gültige Signatur erstellen. Die Echtheit des Dokuments kann dann über
die Verifikation der Unterschrift mittels des zugehörigen öffentlichen bzw. geheimen
Schlüssels geprüft werden. Der geheime Schlüssel wird manchmal auch als privater
Schlüssel bezeichnet.
Ein nicht autorisierter Dritter, der den richtigen Schlüssel nicht kennt, ist nicht in der
Lage, eine gültige Signatur zu erstellen. Wird eine manipulierte und nicht richtig
unterzeichnete Software dann in ein Steuergerät geladen, so wird dies mit dem zu
gehörigen Schlüssel erkannt, und das Steuergerät wird beispielsweise in einen
nicht-lauffähigen Zustand versetzt.
Gemäß einer weiteren Ausführungsform der Erfindung wird der Schlüssel im Boot-
Sektor des Steuergeräts abgelegt. Der Boot-Sektor ist meist in besonderer Weise
geschützt und kann nicht ohne weiteres überschrieben werden. Gemäß einer Wei
terbildung kann der Boot-Sektor nach dem Beschreiben und der Eingabe des
Schlüssels "abgesperrt" werden, so daß ein weiterer Zugriff, insbesondere ein wei
teres Beschreiben, nicht mehr möglich ist. Damit würde sichergestellt werden, daß
der im Boot-Sektor abgelegte Schlüssel gegen Manipulation geschützt ist.
Um die Anforderungen eines ausschließlich fahrzeugindividuellen Einsatzes einer
Software zu ermöglichen, enthält die für ein Steuergerät eines bestimmten Fahr
zeugs vorgesehene Software fahrzeugindividualisierende Informationen, beispiels
weise die Fahrgestellnummer oder andere fahrzeugindividuelle Daten. Diese Infor
mationen sind der Software zugeordnet oder in diese integriert. Erst nach der Zu
ordnung oder Integration dieser Daten zur bzw. in die Software wird diese dann mit
dem dafür vorgesehenen Schlüssel signiert. Ein Steuergerät akzeptiert - wie oben
beschrieben - nur dann die Software, wenn die Signatur mit dem anderen zugeord
neten Schlüssel als einwandfrei erkannt wird. Da die Signatur von der in der Soft
ware enthaltenen fahrzeugindividuellen Information abhängt, kann diese nicht
nachträglich verändert werden. Es kann nur eine Software lauffähig für ein Steuer
gerät eines Fahrzeugs eingespeist werden, wenn die fahrzeugindividuelle Informati
on nicht verändert ist und mit derjenigen des Fahrzeugs tatsächlich übereinstimmt.
Ein Kopieren einer solch fahrzeugindividualisierten Software auf ein anderes Fahr
zeug ist damit unmöglich, da die fahrzeugindividuelle Information ohne Verletzung
der Signatur nicht verändert werden kann.
Um nicht jedesmal beim Start eines Fahrzeugs und dem Hochlaufen der Steuerge
räte eine Überprüfung der Software durchführen zu müssen, wird eine solche Über
prüfung vorzugsweise zumindest beim Einspielen durchgeführt. Bei einer einwand
frei signierten Software kann diese dann entsprechend gekennzeichnet werden,
beispielsweise durch das Setzen eines sonst nicht zu beeinflussenden Flags in dem
Steuergerät. Nach dem Setzen dieses Flags ist die Software auch bei weiteren
Hochläufen akzeptiert. Auf diese Weise können Verzögerungen beim normalen
Fahrzeugstart vermieden werden. Sicherzustellen ist hierbei jedoch, daß dieses
Flag nicht von außen zu beeinflussen ist.
Um eine weitere Sicherheitsstufe beim Einspielen von Software in den Speichern
des Steuergerätes zu schaffen, sollte gemäß einer weiteren Ausführungsform der
Erfindung vor dem Einspielen der Software ein Zugang zum Speicher des Steuer
gerätes nur mit entsprechender Berechtigung möglich sein. Dazu ist vor dem Über
spielen der signierten Software ein "Aufschließen" des Steuergerätes in einem An
meldeschritt vorgesehen. Bei der Verwendung unterschiedlicher Zugangslevel bei
der Anmeldung könnten überdies verschieden ausgestaltete Zugriffsrechte verge
ben werden. Bei einem Diagnosezugriff wäre beispielsweise zunächst eine Anmel
dung notwendig, wodurch das Steuergerät über die eingegebene Zugangsinforma
tion die Zugriffsrechte und die damit verbundene Berechtigungsstufe erkennt. Je
nach Rechtevergabe können die Zugriffsberechtigungen von unkritisch bis sehr
kritisch eingestuft werden. Gemäß einer Ausführungsform wird ein Code vom Steu
ergerät angefordert und auf Gültigkeit überprüft. Dazu kann beispielsweise eine
Zufallszahl im Steuergerät generiert werden, die dann vom Zugreifenden in verar
beiteter Weise, z. B. anders codiert oder signiert, zurückgereicht wird. Im Steuerge
rät wird diese Information dann, beispielsweise mittels eines eigenen Authentifizie
rungsschlüssel, überprüft.
Es ist auch möglich, die Zugriffsrechtevergabe dynamisch zu gestalten. Beispiels
weise können Zugangszertifikate vergeben sein, aus deren Zertifikatsinformationen
die Zugangsstufe hervorgeht. Wird ein Zugangszertifikat dann einmal akzeptiert,
was wiederum über die Prüfung einer Signatur mit einem Schlüssel geschehen
kann, so werden darin aufgelistete Rechte zugestanden.
Ein evtl. ausschließlich für die Zugriffssteuerung vorgesehenes Steuergerät sollte
gegenüber den übrigen Steuergeräten wegen der zentralen Sicherheitsfunktion
hinsichtlich der Vergabe von Authentifizierungsrechten nicht frei zugänglich im
Kraftfahrzeug angeordnet sein, da durch den physikalischen Ausbau eines Steuer
gerätes die oben beschriebenen Schutzmechanismen umgangen werden könnten.
Ein besonderer, beispielsweise mechanischer Ausbauschutz, eines solchen Sicher
heitssteuergerätes ist daher wünschenswert.
Darüber hinaus kann eine besondere Sicherheitsstufe auch durch die Gestaltung
eines Steuergeräteverbundes erreicht werden, bei dem verschiedene Steuergeräte
zusammengeschaltet sind und sich bedingen bzw. gegenseitig überprüfen.
Um ferner die Gefahr auszuschließen, daß einzelne Steuergerät ausgebaut und
gegen ein anderes ersetzt werden, kann zusätzlich ein eigener Steuergeräteaus
bauschutz sinnvoll sein. Zu diesem Zweck wird beispielsweise in einem Fahrzeug,
in dem die Steuergeräte integriert sind, sporadisch eine Steuergeräte-
Authentitätsprüfung durchgeführt. Dazu wird eine Anfrage an Steuergeräte gerich
tet, die diese mit einer bestimmten erwarteten Information beantworten müssen.
Stimmt die tatsächlich von dem zu überprüfenden Steuergerät abgegebenen Infor
mation nicht mit der erwarteten Information überein oder antwortet das Steuergerät
nicht, so werden geeignete Sicherungsmaßnahmen ergriffen. Bei nicht sicherheits
kritischen Steuergeräten kann das Steuergerät beispielsweise aus dem Kommuni
kationsverbund ausgeschlossen werden. Ist das Steuergerät für den Betrieb des
Fahrzeugs wichtig, so wird es beispielsweise registriert, markiert oder in eine Liste
eingetragen, so daß die hardwaremäßige Manipulation am jeweiligen Steuergerät
zumindest nachvollzogen werden kann. Bei einer Ausführungsform müssen die
Steuergeräte auf Anfrage mittels eines geheimen Authentifikationsschlüssel ant
worten. Ein illegal ausgetauschtes Steuergerät verfügt über einen solchen Schlüs
sel nicht und wird dann erkannt und entsprechend behandelt.
Die vorliegende Erfindung wird nachfolgend anhand von Ausführungsbeispielen und
mit Bezug auf die beiliegenden Zeichnungen näher erläutert. Die Zeichnungen zei
gen in
Fig. 1 eine schematische Darstellung einer Steuergerätestruktur in einem
Fahrzeug,
Fig. 2a und
Fig. 2b eine schematische Darstellung des Ablaufs einer digitalen Signatur
einer Software sowie deren Überprüfung,
Fig. 3a und Fig. 3b eine Darstellung des Ablaufs der digitalen Signatur der Software aus
Fig. 2 jedoch in anderer Darstellungsweise,
Fig. 4 eine Darstellung des Ablaufs der Erstellung einer Signatur durch ein
Trust-Center,
Fig. 5 eine Darstellung eines Algorithmus für spezielles Überprüfungsver
fahren von fahrzeugindividuellen Informationen,
Fig. 6a und 6b ein Schaltblock- und Ablaufdiagramm für eine Authentifizierung ge
genüber einem Steuergerät und
Fig. 7 ein Ablaufdiagramm für ein Einlesen von Software in ein Steuergerät.
In Fig. 1 ist in blockdiagrammweise eine Steuergerätestruktur mit miteinander ver
netzten Einheiten abgebildet. Das Boardnetz besteht hierbei aus mehreren Teilnet
zen (LWL-Most, K-CAN System, Powertrain-CAN etc.), die zum Teil unterschiedli
che Übertragungsgeschwindigkeiten besitzen und durch sogenannte Gateways
(Zentrales Gateway Modul, Controller Gateway) miteinander verbunden sind.
Mittels des Zentralen Gateways 14 ist ein Diagnosebus 16 mit allen übrigen Netzen
mittelbar oder unmittelbar gekoppelt. Der Diagnosebus 16 stellt eine der wichtigsten
Verbindungen zur Umwelt dar. Über einen Diagnosetester, der an einer OBD-
Steckdose am Ende des Diagnosebuses 16 angeschlossen ist, und unter Zwi
schenschaltung des zentralen Gateways 14 können sämtliche Controller, Gateways
und Steuergeräte im gesamten System angesprochen werden.
Alternativ besteht die Möglichkeit, über das GSM-Netz 20 und ein Telefonsystem 18
im Fahrzeug auf die Geräte im Fahrzeug zuzugreifen. Damit ist prizipiell ein Remo
tezugriff auf das Fahrzeug-Boardnetz möglich. Das Telefonsystem 18 stellt hierbei
ebenfalls ein Gateway zwischen dem Mobilfunknetz (GSM-Netz) und den übrigen
Fahrzeugbusteilnehmern dar.
Im Fahrzeugbus integriert ist ein Car-Access-System (CAS) 22, das den Zutritt zum
Fahrzeug überwacht. Es beinhaltet als weitere Funktion eine elektronische Weg
fahrsperre.
Ein Controller Gateway 21 stellt eine Schnittstelle zwischen einem CD-Player und
dem Bordnetz dar. Beim Controller Gateway 21 werden auch Eingaben, die der
Fahrer über die verschiedenen Instrumente macht, in Nachrichten umgesetzt und
an die jeweils angesprochenen Steuergeräte weitergeleitet.
Daneben sind mehrere Steuergeräte (STG1 bis STG5) Steuergeräten dargestellt.
Die Aufgabe eines Steuergerätes besteht nicht nur in der Steuerung einer be
stimmten Einheit im Fahrzeug, sondern auch in der Kommunikation zwischen den
Geräten selbst. Die Kommunikation im Fahrzeug ist "Broadcast orientiert". Ein Er
zeuger von Informationen, der den Buszugriff gewonnen hat, sendet seine Informa
tionen grundsätzlich an alle Steuergeräte. Der Datenbus, der mit dem Controller
verbunden ist, wird dazu permanent abgehört. Bei einer Kommunikation mit der
Umwelt hingegen, beispielsweise über den Diagnosebus, wird jedes Steuergerät mit
einer eindeutigen Adresse gezielt angesprochen.
Die Software, die die Funktionalität der Steuereinheit bestimmt, ist in Zukunft über
wiegend in einem programmierbaren Speicher, beispielsweise in einem Flash-
Speicher, untergebracht. Bei einer Flashprogrammierung können nur ganze Blöcke
gelöscht und neu beschrieben werden. Das Löschen einzelner Bits ist nicht möglich.
Je nach Steuergeräten werden unterschiedliche Arten von Mikrocomputern einge
setzt. Je nach Anforderungen sind dies 8-Bit, 16-Bit oder 32-Bit-Prozessoren. Alle
diese Steuergeräte oder Controller sind in unterschiedlichen Varianten verfügbar.
Sie weisen beispielsweise einen Flash-Speicher auf dem Board oder direkt im Pro
zessor selbst integriert auf.
Der Ablauf einer Sicherstellung der Datenintegrität einer Software für ein Steuerge
rät mit einem Flash-Speicher ist nachfolgend anhand der Fig. 2a und 2b näher dar
gestellt.
Zunächst wird in einem ersten Schritt von einer einzigen autorisierten Stelle, bei
spielsweise in einem sogenannten Trust-Center, ein Schlüsselpaar bestehend aus
einem öffentlichen Schlüssel 58 und einem geheimen Schlüssel 52 bereitgestellt.
Ein Schlüssel ist dabei ein elektronischer Code, mit dem eine Information ver-
und/oder entschlüsselt werden kann. Beispielsweise verwendet man dabei be
kannte kryptographische Algorithmen, wie die bereits oben erwähnten RSA oder
DEA Algorithmen, also sogenannte "Public-Key-Algorithmen" mit asynchronen
Schlüsselpaaren.
Zunächst soll näher auf die verwendete Verschlüsselung eingegangen werden. Bei
dem vorliegenden Authentifizierungsverfahren wird eine asynchrone Verschlüsse
lung bevorzugt. Bei symmetrischen Schlüsseln muß jede Seite im Besitz des
"Geheimnisses" sein. Sobald ein synchroner Schlüssel neben den autorisierten
Stellen auch noch Dritten bekannt ist, kann keine einwandfreie Sicherungsvorkeh
rung garantiert werden. Da ein Schlüssel des Schlüsselpaares bei dem vorliegen
den Verfahren jedoch im Steuergerät eines Kraftfahrzeugs abgespeichert sein muß
und somit dessen Geheimhaltung nicht sichergestellt werden kann, ist die Wahl
eines symmetrischen Schlüsselpaares nicht ratsam.
Im Gegensatz zu der symmetrischen Verschlüsselung entwickelten W. Diffie und M.
Hellman 1976 die sogenannte Public-Key-Kryptografie. Bei dieser Verschlüsse
lungsart wird ein Schlüsselpaar mit einem öffentlichen und einem geheimen
Schlüssel erzeugt. Mit dem geheimen Schlüssel kann man eine Signatur eines
elektronischen Dokumentes durchführen. Diese Signatur ist einzigartig und kann in
der Regel nicht nachvollzogen werden. Mit dem öffentlichen Schlüssel kann die
Signatur überprüft werden.
Das Public-Key-Verfahren hat den Vorteil, daß ein Schlüssel des Schlüsselpaares
öffentlich bekannt sein darf. Da die heute bekannten Public-Key-Verfahren aber
sehr rechenintensiv sind, verwendet man häufig Hybrid-Verfahren, also eine Kombination
aus symmetrischen und asymmetrischen Verfahren. Bei dem Hybrid-
Verfahren wird ein symmetrischer Schlüssel mittels eines Public-Key-Verfahrens
zwischen den Kommunikationspartnern ausgetauscht. Die eigentliche Kommunika
tion wird dann mit dem symmetrischen Schlüssel verschlüsselt.
Durch die Trennung von geheimen und öffentlichen Schlüsseln lassen sich Authen
tifizierungsverfahren und digitale Signaturen wie oben beschrieben realisieren.
Durch den Besitz des geheimen Schlüssels läßt sich eine Identität eindeutig nach
weisen, und es kann eine Signatur, wie bei einer handschriftlichen Unterschrift er
stellt werden. Ein bekanntes Public-Key-Kryptosysteme ist das oben bereits er
wähnte RSA-Verfahren. Andere Public-Key-Krypto-Verfahren beruhen auf Proble
men in bestimmten mathematischen Gruppen, Logarithmen zu berechnen
(Diskreter-Logarithmus-Problem).
Um ein Dokument digital zu signieren, verschlüsselt die alleinig autorisierte Stelle
das Dokument mit dem geheimen Schlüssel und hängt einen Signaturwert an das
Dokument an. Zur Verifikation der Signatur wie die Signatur mit dem öffentlichen
Schlüssel entschlüsselt und der resultierende Wert mit dem ursprünglichen Doku
mentenwert verglichen. Stimmen beide Dokumentenwerte überein, so ist die Si
gnatur gültig und die Software kann akzeptiert werden.
Vorliegend ist jeweils ein öffentlicher Schlüssel von der autorisierten Stelle bei der
Fahrzeugproduktion in jedem Steuergerät eines Fahrzeugs, welches bezüglich der
Software modifizierbar sein soll (z. B. Getriebesteuergerät), abgespeichert.
Ein Kunde bestellt nun bei einem Händler 100 (vgl. Fig. 4) eine bestimmte zusätzli
che Funktion für sein Kraftfahrzeug, beispielsweise eine bestimmte Schaltcharakte
ristik bei der Auswahl der Übersetzungsstufen. Diese Funktion kann durch die Ein
spielung neuer Software in ein Getriebesteuergerät des jeweiligen Fahrzeugs reali
siert werden.
Der Händler 100 stellt daraufhin eine entsprechende Software 150 zur Verfügung
und sendet diese zusammen mit der Fahrgestellnummer des Fahrzeugs des Kun
den zum Trust-Center 104, welches alleinig berechtigt ist, diese Software zu unterzeichnen
(signieren). Im Trust-Center 104 wird die Software zusammen mit der
übermittelten Fahrgestellnummer mit dem geheimen Schlüssel signiert.
Diese Vorgehensweise ist auch in Fig. 2a dargestellt (Software 50, geheimer
Schlüssel 52), wobei hier jedoch keine Fahrgestellnummer übermittelt wird.
Die signierte Software 106 (vergl. Fig. 4 und Bezugszeichen 56 in Fig. 2a) wird
dann an den Händler 100 zurückübermittelt, welcher sie ins Kraftfahrzeug 12 des
Kunden einspielen kann.
Die Übermittlung an das Trust-Center 104, die Signierung und das Zurückübermit
teln kann auf elektronischem Weg relativ schnell geschehen.
Im nächsten Schritt wird die signierte Software 56, 106 vom Händler 100 in das
Fahrzeug 12, besser in das Getriebesteuergerät, eingespielt. Die Übertragung kann
über den Diagnosestecker und den Diagnosebus 16 erfolgen. Alternativ kann eine
Einspielung auch über das GSM-Netz ferngesteuert erfolgen.
Beim Einspielen erfolgt zunächst eine Anmeldung und Identifizierung des Händlers
(vgl. Schritt 500 in Fig. 7). Dazu sendet der Händler 100 eine Steuergeräteadresse
und eine zugehörige Kennung an das Fahrzeug. Bei erfolgreicher Identifizierung
wird das Steuergerät (hier: das Getriebesteuergerät) zum Einlesen von neuer Soft
ware bereitgeschaltet. Damit ist das Einlesen (auch Flashen) von neuer Software in
das Steuergerät möglich (vgl. 502 in Fig. 7). Nach dem Einspielen der neuen Soft
ware in das Steuergerät hat der Händler 100 seinen Teil geleistet.
Beim nächsten Betrieb überprüft das Steuergerät 24 (Fig. 2) beim Hochlaufen die
Signatur der eingespielten neuen Software 56 mittels des öffentlichen Schlüssels
58. Dies wird anhand von Fig. 2b näher erläutert. Mit dem öffentlichen Schlüssel 58
wird aus der Signatur in einer Einheit 60 des Steuergerätes 24 eine Größe be
stimmt, die mit dem elektronischen Dokument 62, welches verschlüsselt worden ist,
übereinstimmen muß. Diese Übereinstimmung wird in einem Komparator 64 ge
prüft. Ist eine Übereinstimmung gegeben, so wird die eingespielte Software 50 ak
zeptiert und das Steuergerät 24 mit dieser Software betrieben. Ist keine Übereinstimmung
gegeben, so wird das Steuergerät 24 markiert und in einer Liste abge
speichert. Bei einer Diagnose können die Daten dieser Liste dann ausgelesen wer
den. Es wird dann eine weitere Gelegenheit zum Einspielen korrekter Software ge
geben. Wird keine korrekt signierte Software eingespielt, kann das Fahrzeug nicht
weiter betrieben werden.
In den Fig. 3a und 3b ist die Ver- und Entschlüsselung etwas genauer dargestellt.
Bei der Signatur der Software wird nicht die gesamte Software signiert. Dies wäre
ineffizient. Vielmehr wird aus der Software über eine an sich bekannte Hash-
Funktion ein sogenannter Hash-Code 51 generiert, bei dem es sich um eine digitale
Information mit vorgegebener Länge handelt. Je nach Sicherheitsbedürfnis kann
eine Länge von z. B. 16 Bit, 64 Bit oder 128 Bit gewählt werden. Erst dieser Hash-
Code 51 wird dann signiert (Signatur 54) und die Signatur an die Software 50 ange
hängt. Die Signierung des Hash-Codes ist wesentlich effizienter als die Signatur
von langen Software-Dokumenten.
Die Hash-Funktionen haben dabei folgende wesentliche Eigenschaften: Es ist
schwer, zu gegebenem Hash-Wert h einen Wert M eines Dokuments zu finden
(Einwegfunktion). Zudem ist es schwer, eine Kollision, d. h. zwei Werte mit M und
M', bei denen die Hash-Werte gleich sind, zu finden (Kollisionsresistenz).
Bei der Überprüfung der Signatur 50 wird durch Anwenden des öffentlichen Schlüs
sels auf die Signatur (Bezugszeichen 53 in Fig. 3b) ein Hash-Wert 51' ermittelt, der
mit dem tatsächlichen Hash-Wert 51 der Software 50 in einem Komparator 66 ver
glichen wird. Stimmen beide Hash-Werte überein, so wird die Software 50 akzep
tiert. Es handelt sich dann um eine authentische Software und das Steuergerät
kann mit der eingespielten Software betrieben werden. Ist der Vergleich nicht posi
tiv, bricht das Steuergerät seinen Betrieb ab und wartet bis eine einwandfreie Soft
ware mit ordnungsgemäßer Signatur eingespielt worden ist.
Neben dem oben beschriebenen Authentifizierungsablauf wird zur Authentifikation
eines Kommunikationspartners A gegenüber einem Kommunikationspartners B
häufig auch ein sogenanntes Challenge-Response-Verfahren verwendet. Dabei
sendet B zunächst eine Zufallszahl RND an A. A signiert diese Zufallszahl mittels
seines geheimen Schlüssels und sendet diesen Wert als Antwort an B. B verifiziert
die Antwort mittels seines öffentlichen Schlüssels und prüft die Authentifizierung
von A.
Eine solche Authentifizierung ist in den Fig. 6a und 6b dargestellt. In Fig. 6a ist die
Kommunikationsschleife zwischen einem Diagnosetester und einem Steuergerät
dargestellt. Bei der Authentifizierung nach dem Challenge-Response-Verfahren
sendet ein Benutzer mittels des Diagnosetesters zunächst eine Information mit ei
nem bestimmten Zugriffslevel LI an das Steuergerät und fordert eine Zufallszahl
von dem Steuergerät an (Schritt 400). Das Steuergerät antwortet mit der Übertra
gung einer Zufallszahl (Schritt 402). Im Diagnosetester wird die Zufallszahl mit ei
nem geheimen Schlüssel signiert und dann wird das Ergebnis wieder an das Steu
ergerät geschickt (Schritt 404). Im Steuergerät wird aus der Signatur mithilfe des
öffentlichen Schlüssels wiederum die Zufallszahl bestimmt. Stimmt die so errech
nete Zahl mit der vorher vom Steuergerät übermittelten Zufallszahl überein, wird der
Zugriff für diesen Benutzer mit der gewünschten Sicherheitsstufe für die Dauer des
Diagnoseverfahrens freigegeben. Damit kann er bei entsprechender Sicherheitsein
stufung ein Software in den Speicher eines Steuergerätes einlesen.
Nachfolgend wird die Individualisierung der Software für ein bestimmtes Fahrzeug
beschrieben. Bereits bei der Bezugnahme auf den Signiervorgang gemäß Fig. 4
wurde erwähnt, daß mit der Software eine Fahrzeugidentifikation übermittelt wird,
die lediglich auf ein bestimmtes Fahrzeug zutrifft. Die Software wird dann zusam
men mit der Fahrzeugidentifikation (z. B. der Fahrgestellnummer) signiert und das
Paket an den Händler zurückgeschickt. Die Signatur ging dabei in den Hash-Code
(beschrieben bei der Ausführungsform gemäß der Fig. 3a und 3b) ein und beein
flußt die Signatur entscheidend mit.
Das Steuergerät akzeptiert - wie bereits oben beschrieben - nur eine korrekt si
gnierte Software. ist die Signatur korrekt, wird ferner überprüft, ob die der Software
zugeordnete Fahrzeugidentifikation mit derjenigen des Fahrzeug tatsächlich über
einstimmt. Würde dies der Fall sein, so würde die Software freigeschaltet. Mit die
ser Vorgehensweise kann die fahrzeugindividualisierte Software nur in einem bestimmten
Zielfahrzeug verwendet werden. Für ein anderes Fahrzeug muß wiederum
eine andere mit einer individuellen Signatur versehene Software beschafft werden.
Um eine Individualisierung einer Software durchführen zu können, sollte die Fahr
gestellnummer bereits in der Fertigung in die entsprechenden Steuergeräte in nicht
manipulierbarer Weise eingetragen werden. Die Fahrgestellnummer muß auch
nach einem Löschen eines Speichers noch in dem Steuergerät vorhanden sein.
Dies kann dadurch realisiert werden, daß die Fahrgestellnummer beispielsweise in
dem oben bereits erwähnten und besonders geschützen Car-Access-System in
einem nicht flüchtigen und nicht austauschbaren Speicher eingetragen ist.
Folgende Vorgehensweise gemäß Fig. 5 sichert eine nicht manipulierbare Abfrage.
Zusätzlich zur Fahrgestellnummer benötigt man ein weiteres fahrzeugindividuelles
Schlüsselpaar bestehend aus einem geheimen Schlüssel IFSs und einem öffentli
chen Schlüssel IFSp. Die Zuordnung der Fahrgestellnummer und der beiden
Schlüssel erfolgt an zentraler Stelle, also in dem Trust-Center. Der geheime
Schlüssel IFSs ist in einem Car-Access-System 210 gespeichert und zwar in nicht
auslesbarer Form.
Die Fahrgestellnummer befindet sich auch heute bereits im Zugriffsbereich des Car-
Access-Systems 210.
In der neu einzuspielenden Software wird nun zusätzlich zur Fahrgestellnummer
noch der öffentliche fahrzeugindividuelle Schlüssel IFSp 202 hinterlegt (Schritt 200
in Fig. 5). Danach wird die gesamte Software im Trust-Center durch die Signatur
204 gesichert. Nach dem Einspielen der Software in das Steuergerät wird zunächst
die Korrektheit der Signatur 204 geprüft.
Danach überprüft das Steuergerät 206 mittels der vorher beschriebenen Challenge-
Response-Abfrage, ob die Fahrgestellnummer in der Software mit derjenigen des
Fahrzeugs übereinstimmt. Dazu sendet das Steuergerät 206 die in der Software
enthaltene Fahrgestellnummer FGNsw und eine Zufallszahl RANDOM an das Car-
Access-System 210. Dort wird die gespeicherte Fahrgestellnummer FGN mit der
empfangenen Fahrgestellnummer FGNsw verglichen. Anschließend werden die
beiden Werte mit dem geheimen Schlüssel IFSs signiert und wieder an das Steuer
gerät 206 zurück gesendet. Das Steuergerät 206 kann nun mit dem öffentlichen
Schlüssel IFSp die signierte Sendung überprüfen und die erhaltenen Werte mit dem
Challenge-Wert vergleichen, der am Anfang an das Car-Access-System gesendet
wurde. Stimmen die Werte überein, so kann die Software akzeptiert werden (Schritt
216, o. k.). Ansonsten wird die Software nicht akzeptiert (Schritt 218, Nein).
Als Variante dieses Verfahren kann anstelle eines individuellen Schlüsselpaares
lFSs und IFSp auch ein entsprechendes nicht fahrzeugindividualisiertes Schlüssel
paar, das bereits im Fahrzeug gespeichert ist, verwendet werden. Dadurch entfällt
die Verwaltung für diesen Schlüssel. Ebenso ist natürlich ein entsprechender Me
chanismus mit einem symmetrischen kryptografischen Verfahren möglich. Dies hat
zwar Vorteile bei der Abarbeitung, bringt aber die Gefahr des Auslesens des sym
metrischen Schlüssels aus den Steuergeräten mit sich.
Natürlich ist bei allen oben genannten Verfahren absolut sicherzustellen, daß die
geheimen Schlüssel des Trust-Centers auch geheim bleiben. Insgesamt bietet die
vorgenannte Kryptografie eine gute Möglichkeit, nur ordnungsgemäße Software in
Fahrzeuge, bzw. in bestimmte Fahrzeuge einzuspielen und somit unbefugten Mani
pulationen vorzubeugen.
Claims (20)
1. Verfahren zur Sicherstellung der Datenintegrität einer Software für ein Steu
ergerät eines Kraftfahrzeugs, in dem in einem Speicher des Steuergeräts ei
ne das Steuergerät in seiner Wirkungsweise beeinflussende Software spei
cherbar ist, gekennzeichnet durch die Schritte:
Bereitstellen eines Schlüsselpaares zum Ver- und Entschlüsseln von elek tronischen Daten,
Hinterlegen eines ersten Schlüssels in einem oder für ein Steuergerät in dem Kraftfahrzeug,
Signieren einer einzuspielenden Software mit dem zweiten Schlüssel,
Einspielen der signierten Software in den Speicher des Steuergerätes,
Überprüfung der Signatur der Software mittels dem in oder für das Steuer gerät hinterlegten Schlüssel und Akzeptieren der eingespielten Software, wenn die Überprüfung mit positivem Ergebnis verläuft.
Bereitstellen eines Schlüsselpaares zum Ver- und Entschlüsseln von elek tronischen Daten,
Hinterlegen eines ersten Schlüssels in einem oder für ein Steuergerät in dem Kraftfahrzeug,
Signieren einer einzuspielenden Software mit dem zweiten Schlüssel,
Einspielen der signierten Software in den Speicher des Steuergerätes,
Überprüfung der Signatur der Software mittels dem in oder für das Steuer gerät hinterlegten Schlüssel und Akzeptieren der eingespielten Software, wenn die Überprüfung mit positivem Ergebnis verläuft.
2. Verfahren nach Anspruch 1,
dadurch gekennzeichnet,
daß ein symmetrisches Schlüsselpaar verwendet wird, bei dem beide
Schlüssel gleich sind.
3. Verfahren nach Anspruch 1,
dadurch gekennzeichnet,
daß ein asymmetrisches Schlüsselpaar mit einem geheimen und einem öf
fentlichen Schlüssel verwendet wird.
4. Verfahren nach Anspruch 3,
dadurch gekennzeichnet,
daß der öffentliche Schlüssel im oder für das Steuergerät hinterlegt ist und
mit dem geheimen Schlüssel die Software signiert wird.
5. Verfahren nach Anspruch 3,
dadurch gekennzeichnet,
daß das Fahrzeug, insbesondere das oder ein Steuergerät im Fahrzeug, ein
asynchrones Schlüsselpaar erzeugt, daß der geheime Schlüssel im Fahr
zeug, insbesondere in einem Steuergerät, hinterlegt wird und daß der öffent
liche Schlüssel zum Signieren einer Software aus dem Fahrzeug auslesbar
ist.
6. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet,
daß der im Steuergerät abgelegte Schlüssel im Boot-Sektor abgelegt wird.
7. Verfahren nach Anspruch 6,
dadurch gekennzeichnet,
daß der Bootsektor nach dem Beschreiben und der Eingabe des Schlüssels
abgesperrt wird und so gegen einen weiteren Zugriff, insbesondere einen
Schreibzugriff, geschützt ist.
8. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet,
daß die Software zunächst auf eine Information mit bestimmter Länge abge
bildet wird und diese Information dann signiert wird.
9. Verfahren nach Anspruch 8,
dadurch gekennzeichnet,
daß als Abbildungsfunktion eine Hash-Funktion gewählt wird.
10. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet,
daß der Software zumindest eine fahrzeugindividuelle Information eines das
Steuergerät enthaltenden Fahrzeugs hinzugefügt wird, daß mit der Software
die zumindest eine fahrzeugindividuelle Information signiert wird, daß neben
dem Überprüfen der Signatur der Software auch die fahrzeugindividuelle
Information überprüft wird und daß die Software nur dann im Steuergerät
akzeptiert wird, wenn auch die fahrzeugindividuelle Information der Software
mit derjenigen des Fahrzeugs übereinstimmt.
11. Verfahren nach Anspruch 10,
dadurch gekennzeichnet,
daß zur Überprüfung der fahrzeugindividuellen Information ein eigenes
Schlüsselpaar (fahrzeugindividuelles Schlüsselpaar) erzeugt wird, wobei in
einer Fahrzeugsicherheitseinheit die fahrzeugindividuelle Information und ein
erster Schlüssel des eigenen Schlüsselpaares vorhanden sind, in der Soft
ware neben der fahrzeugindividuellen Information noch der zweite Schlüssel
des eigenen Schlüsselpaares abgelegt ist und in einer separaten Routine im
Fahrzeug überprüft wird, ob die beiden Schlüssel des eigenen Schlüsselpaa
res zusammenstimmen, um bei einer Bejahung die eingespielte Software zu
akzeptieren.
12. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet,
daß die Software zumindest beim erstmaligen Hochlaufen des Steuergerä
tes geprüft und dann entsprechend gekennzeichnet wird.
13. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet,
daß bei einem externen Zugriff auf das Steuergerät eine Zugangseinheit
prüft, ob eine Berechtigung für den Zugriff vorliegt.
14. Verfahren nach Anspruch 13,
dadurch gekennzeichnet,
daß ein Code von einem Steuergerät angefordert wird und der Code auf
Richtigkeit überprüft wird.
15. Verfahren nach Anspruch 13 oder 14,
dadurch gekennzeichnet,
daß ein Steuergerät eine Zufallszahl ausgibt, die von dem Zugreifer zu si
gnieren ist und daß die Signatur im Steuergerät, insbesondere mittels eines
Authentifizierungsschlüssels, überprüft wird.
16. Verfahren nach einem der Ansprüche 13 bis 15,
dadurch gekennzeichnet,
daß bei der Abfrage der Zugriffsberechtigung eine Berechtigungsstufe fest
gestellt wird und Zugriffsaktionen in Abhängigkeit von der Berechtigungs
stufe akzeptiert oder nicht akzeptiert werden.
17. Verfahren nach einem der vorhergehenden Ansprüche,
dadurch gekennzeichnet,
daß eine Sicherheitseinrichtung in einem Fahrzeug zumindest sporadisch
eine Authentitätsprüfung eines Steuergerätes durchführt und das Steuerge
rät bei negativem Ergebnis registriert.
18. Verfahren nach Anspruch 17,
dadurch gekennzeichnet,
daß im Steuergerät ein steuergeräteindividueller geheimer Code hinterlegt
ist.
19. Verfahren nach Anspruch 17 oder 18,
dadurch gekennzeichnet,
daß die Sicherheitseinrichtung ein steuergerätespezifisches Merkmal abfrägt
und dieses auf Authentität prüft.
20. Verfahren nach einem der Ansprüche 17 bis 19,
dadurch gekennzeichnet,
daß bei der Authentitätsprüfung ein in der Sicherheitseinrichtung und/oder
ein in dem Steuergerät hinterlegter Schlüssel verwendet wird.
Priority Applications (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE10008974A DE10008974B4 (de) | 2000-02-25 | 2000-02-25 | Signaturverfahren |
EP01101343.0A EP1128242B1 (de) | 2000-02-25 | 2001-01-22 | Signaturverfahren |
ES01101343.0T ES2530229T3 (es) | 2000-02-25 | 2001-01-22 | Procedimiento de firma |
JP2001032507A JP4733840B2 (ja) | 2000-02-25 | 2001-02-08 | 署名方法 |
US09/792,053 US6816971B2 (en) | 2000-02-25 | 2001-02-26 | Signature process |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE10008974A DE10008974B4 (de) | 2000-02-25 | 2000-02-25 | Signaturverfahren |
Publications (2)
Publication Number | Publication Date |
---|---|
DE10008974A1 true DE10008974A1 (de) | 2001-09-06 |
DE10008974B4 DE10008974B4 (de) | 2005-12-29 |
Family
ID=7632446
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE10008974A Expired - Fee Related DE10008974B4 (de) | 2000-02-25 | 2000-02-25 | Signaturverfahren |
Country Status (5)
Country | Link |
---|---|
US (1) | US6816971B2 (de) |
EP (1) | EP1128242B1 (de) |
JP (1) | JP4733840B2 (de) |
DE (1) | DE10008974B4 (de) |
ES (1) | ES2530229T3 (de) |
Cited By (21)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE10143556A1 (de) * | 2001-09-06 | 2003-03-27 | Daimler Chrysler Ag | Fahrzeugmanagementsystem |
DE10141737C1 (de) * | 2001-08-25 | 2003-04-03 | Daimler Chrysler Ag | Verfahren zur sicheren Datenübertragung innerhalb eines Verkehrsmittels |
EP1346881A2 (de) | 2002-03-23 | 2003-09-24 | DaimlerChrysler AG | Verfahren und Vorrichtung zum Übernehmen von Daten |
DE10237698A1 (de) * | 2002-08-15 | 2004-02-26 | Volkswagen Ag | Verfahren und Vorrichtung zur Übertragung von Daten |
DE10238094A1 (de) * | 2002-08-21 | 2004-03-11 | Audi Ag | Verfahren zum Schutz gegen Manipulationen in einem Steuergerät für mindestens eine Kfz-Komponente und Steuergerät |
EP1413939A1 (de) * | 2002-10-24 | 2004-04-28 | Siemens Aktiengesellschaft | Programmier- und Betriebsverfahren für eine programmierbare industrielle Steuerung, insbesondere eine CNC-Steuerung |
DE10255805A1 (de) * | 2002-11-29 | 2004-06-09 | Adam Opel Ag | Verfahren zur Änderung der Programmierung eines Steuergerätes eines Kraftfahrzeuges |
DE10309507A1 (de) * | 2003-03-05 | 2004-09-16 | Volkswagen Ag | Verfahren und Einrichtung zur Wartung von sicherheitsrelevanten Programmcode eines Kraftfahrzeuges |
WO2004090695A1 (de) * | 2003-04-12 | 2004-10-21 | Daimlerchrysler Ag | Verfahren zur überprüfung der datenintegrität von software in steuergeräten |
WO2004095238A1 (de) * | 2003-04-19 | 2004-11-04 | Daimlerchrysler Ag | Verfahren zur sicherstellung der integrität und authentizität von flashware für steuergeräte |
WO2004114131A1 (de) * | 2003-06-24 | 2004-12-29 | Bayerische Motoren Werke Aktiengesellschaft | Verfahren zum nachladen einer software in den bootsektor eines programmierbaren lesespeicher |
WO2005016708A1 (de) * | 2003-07-17 | 2005-02-24 | Continental Aktiengesellschaft | Steuerungs- und regelungsgerät in einem kraftfahrzeug sowie verfahren zum betreiben desselben |
WO2005093567A1 (de) * | 2004-03-09 | 2005-10-06 | Bayerische Motoren Werke Aktiengesellschaft | Aktualisierung und/oder erweiterung der funktionalität der ablaufsteuerung mindestens eines steuergeräts |
DE102004036810A1 (de) * | 2004-07-29 | 2006-03-23 | Zf Lenksysteme Gmbh | Kommunikationsverfahren für wenigstens zwei Systemkomponenten eines Kraftfahrzeugs |
DE102006040228A1 (de) * | 2006-08-28 | 2008-03-06 | Giesecke & Devrient Gmbh | Identifikationssystem |
WO2011051128A1 (de) * | 2009-10-30 | 2011-05-05 | Continental Automotive Gmbh | Verfahren zum betreiben eines tachographen und tachograph |
US8032878B2 (en) | 2005-07-20 | 2011-10-04 | Denso Corporation | Data reprogramming method and system |
DE102010015648A1 (de) * | 2010-04-20 | 2011-10-20 | Siemens Aktiengesellschaft | Messgerät und Messverfahren |
DE102010038179A1 (de) * | 2010-10-14 | 2012-04-19 | Kobil Systems Gmbh | Individuelle Aktualisierung von Computerprogrammen |
DE102015011920A1 (de) | 2015-09-03 | 2017-03-09 | Continental Automotive Gmbh | Verfahren zur Überprüfung der Datenintegrität einer C2C Übertragung |
DE102019206302A1 (de) * | 2019-05-02 | 2020-11-05 | Continental Automotive Gmbh | Verfahren und Vorrichtung zum Übertragen eines Boot-Codes mit verbesserter Datensicherheit |
Families Citing this family (65)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE10008973B4 (de) * | 2000-02-25 | 2004-10-07 | Bayerische Motoren Werke Ag | Autorisierungsverfahren mit Zertifikat |
US20030126453A1 (en) * | 2001-12-31 | 2003-07-03 | Glew Andrew F. | Processor supporting execution of an authenticated code instruction |
DE10215626B4 (de) * | 2002-04-09 | 2007-09-20 | Robert Bosch Gmbh | Verfahren zur Änderung von Verschlüsselungsalgorithmen bei geschützter Software oder geschützten Daten |
US7010682B2 (en) * | 2002-06-28 | 2006-03-07 | Motorola, Inc. | Method and system for vehicle authentication of a component |
US7228420B2 (en) | 2002-06-28 | 2007-06-05 | Temic Automotive Of North America, Inc. | Method and system for technician authentication of a vehicle |
US20040001593A1 (en) * | 2002-06-28 | 2004-01-01 | Jurgen Reinold | Method and system for component obtainment of vehicle authentication |
US7600114B2 (en) * | 2002-06-28 | 2009-10-06 | Temic Automotive Of North America, Inc. | Method and system for vehicle authentication of another vehicle |
US7137142B2 (en) * | 2002-06-28 | 2006-11-14 | Motorola, Inc. | Method and system for vehicle authentication of a component using key separation |
US7127611B2 (en) * | 2002-06-28 | 2006-10-24 | Motorola, Inc. | Method and system for vehicle authentication of a component class |
US7549046B2 (en) * | 2002-06-28 | 2009-06-16 | Temic Automotive Of North America, Inc. | Method and system for vehicle authorization of a service technician |
US20040003234A1 (en) * | 2002-06-28 | 2004-01-01 | Jurgen Reinold | Method and system for vehicle authentication of a subassembly |
US7325135B2 (en) * | 2002-06-28 | 2008-01-29 | Temic Automotive Of North America, Inc. | Method and system for authorizing reconfiguration of a vehicle |
US20040003230A1 (en) * | 2002-06-28 | 2004-01-01 | Puhl Larry C. | Method and system for vehicle authentication of a service technician |
US7131005B2 (en) * | 2002-06-28 | 2006-10-31 | Motorola, Inc. | Method and system for component authentication of a vehicle |
US20040003232A1 (en) * | 2002-06-28 | 2004-01-01 | Levenson Samuel M. | Method and system for vehicle component authentication of another vehicle component |
US7181615B2 (en) * | 2002-06-28 | 2007-02-20 | Motorola, Inc. | Method and system for vehicle authentication of a remote access device |
US7137001B2 (en) * | 2002-06-28 | 2006-11-14 | Motorola, Inc. | Authentication of vehicle components |
DE10229704A1 (de) * | 2002-07-02 | 2004-01-29 | Endress + Hauser Process Solutions Ag | Verfahren zum Schutz vor unerlaubtem Zugriff auf ein Feldgerät in der Prozessautomatisierungstechnik |
BRPI0407722B1 (pt) * | 2003-02-21 | 2017-03-14 | Blackberry Ltd | sistema e método de controle de múltiplos níveis de dispositivos eletrônicos |
DE10357032A1 (de) * | 2003-06-24 | 2005-01-13 | Bayerische Motoren Werke Ag | Verfahren zum Nachladen einer Software in den Bootsektor eines programmierbaren Lesespeicher |
DE10354107A1 (de) * | 2003-07-04 | 2005-01-20 | Bayerische Motoren Werke Ag | Verfahren zur Authentifikation von insbesondere in ein Steuergerät eines Kraftfahrzeugs ladbaren Softwarekomponenten |
JP2007527044A (ja) * | 2003-07-04 | 2007-09-20 | バイエリッシェ モートーレン ウエルケ アクチエンゲゼルシャフト | 特に自動車の制御装置内にロード可能なソフトウェアコンポーネントを認証するための方法 |
JP2005202503A (ja) * | 2004-01-13 | 2005-07-28 | Hitachi Ltd | 車載情報装置、車載機器管理システム、車両の制御機器のプログラムのバージョンアップ情報の配信方法、車両の制御機器のプログラムのバージョンアップ方法及び車両の制御機器のプログラムのバージョンアップシステム |
SE0400480L (sv) * | 2004-02-26 | 2005-08-27 | Movimento Ab | Fordonsinterface |
EP1740418B1 (de) * | 2004-04-29 | 2012-06-13 | Bayerische Motoren Werke Aktiengesellschaft | Authentisierung einer fahrzeugexternen vorrichtung |
US9489496B2 (en) | 2004-11-12 | 2016-11-08 | Apple Inc. | Secure software updates |
JP4534731B2 (ja) * | 2004-11-19 | 2010-09-01 | 株式会社デンソー | 電子制御装置及びその識別コード生成方法 |
JP2006285849A (ja) * | 2005-04-04 | 2006-10-19 | Xanavi Informatics Corp | ナビゲーション装置 |
DE102005039128A1 (de) * | 2005-08-18 | 2007-02-22 | Siemens Ag | Sicherheitseinrichtung für elektronische Geräte |
US20070112773A1 (en) * | 2005-11-14 | 2007-05-17 | John Joyce | Method for assuring flash programming integrity |
DE102005060902A1 (de) * | 2005-12-20 | 2007-06-28 | Robert Bosch Gmbh | Steuergerät für eine Maschine |
EP1857897B1 (de) * | 2006-05-15 | 2014-01-15 | ABB PATENT GmbH | Verfahren und System zur Erstellung oder Änderung sicherheitsrelevanter Daten für eine Steuerungseinrichtung |
DE102006032065A1 (de) * | 2006-07-11 | 2008-01-17 | Knorr-Bremse Systeme für Nutzfahrzeuge GmbH | Neuprogrammierung von elektronischen Fahrzeug-Steuereinheiten über eingebaute Peripherien für austauschbare Datenspeicher |
JP2008059450A (ja) * | 2006-09-01 | 2008-03-13 | Denso Corp | 車両情報書換えシステム |
US20080101613A1 (en) | 2006-10-27 | 2008-05-01 | Brunts Randall T | Autonomous Field Reprogramming |
DE102007004646A1 (de) * | 2007-01-25 | 2008-07-31 | Siemens Ag | Verfahren und Vorrichtung zum Freigeben eines Zugriffs auf eine Steuervorrichtung |
DE102007004645A1 (de) * | 2007-01-25 | 2008-07-31 | Siemens Ag | Tachograph |
DE102007049151B4 (de) * | 2007-10-12 | 2014-05-28 | Robert Bosch Gmbh | Verfahren zur Durchführung einer automotiven Anwendung |
DE102007056662A1 (de) * | 2007-11-24 | 2009-05-28 | Bayerische Motoren Werke Aktiengesellschaft | System zur Freischaltung der Funktionalität einer Ablaufsteuerung, die in einem Steuergerät eines Kraftfahrzeugs gespeichert ist |
DE102008056745A1 (de) * | 2008-11-11 | 2010-05-12 | Continental Automotive Gmbh | Vorrichtung zum Steuern einer Fahrzeugfunktion und Verfahren zum Aktualisieren eines Steuergerätes |
CN102065156B (zh) * | 2009-11-11 | 2013-08-07 | 中兴通讯股份有限公司 | 一种用于断开手持终端下载通道的装置及方法 |
JP5395036B2 (ja) * | 2010-11-12 | 2014-01-22 | 日立オートモティブシステムズ株式会社 | 車載ネットワークシステム |
DE102010053488A1 (de) | 2010-12-04 | 2012-06-06 | Audi Ag | Verfahren zum reversiblen, manipulationssicheren Codieren eines Motorsteuergeräts für ein Kraftfahrzeug und Motorsteuergerät |
FR2973136A1 (fr) | 2011-03-25 | 2012-09-28 | France Telecom | Verification de l'integrite de donnees d'un equipement embarque dans un vehicule |
DE102011109426A1 (de) * | 2011-08-04 | 2012-12-27 | Daimler Ag | Verfahren zur Erkennung von Datenänderungen in einem Steuergerät |
DE102011084569B4 (de) * | 2011-10-14 | 2019-02-21 | Continental Automotive Gmbh | Verfahren zum Betreiben eines informationstechnischen Systems und informationstechnisches System |
EP2786543B1 (de) * | 2011-12-01 | 2019-03-27 | Intel Corporation | Sichere filterung von meldungen an elektronische fahrzeugsteuereinheiten mit sicherer bereitstellung von nachrichtenfilterungsregeln |
ITVI20120034A1 (it) | 2012-02-09 | 2013-08-10 | Bentel Security S R L | Dispositivo e metodo per la gestione di installazioni elettroniche di edifici |
DE102013101508A1 (de) * | 2012-02-20 | 2013-08-22 | Denso Corporation | Datenkommunikationsauthentifizierungssystem für ein Fahrzeug, Netzkopplungsvorrichtung für ein Fahrzeug, Datenkommunikationssystem für ein Fahrzeug und Datenkommunikationsvorrichtung für ein Fahrzeug |
JP6009290B2 (ja) * | 2012-09-12 | 2016-10-19 | 株式会社ケーヒン | 車両の電子制御装置 |
KR101438978B1 (ko) | 2012-12-31 | 2014-09-11 | 현대자동차주식회사 | 리프로그래밍 방법 및 시스템 |
US9179311B2 (en) * | 2013-10-04 | 2015-11-03 | GM Global Technology Operations LLC | Securing vehicle service tool data communications |
DE102014107474A1 (de) * | 2014-05-27 | 2015-12-03 | Jungheinrich Aktiengesellschaft | Flurförderzeug mit einer Diagnoseschnittstelle und Verfahren zum Warten eines solchen Flurförderzeugs |
JP6228093B2 (ja) * | 2014-09-26 | 2017-11-08 | Kddi株式会社 | システム |
CN110377310B (zh) * | 2014-11-12 | 2023-04-07 | 松下电器(美国)知识产权公司 | 更新管理方法、更新管理装置以及计算机可读取的记录介质 |
DE102015201298A1 (de) * | 2015-01-26 | 2016-07-28 | Robert Bosch Gmbh | Verfahren zum kryptographischen Bearbeiten von Daten |
JP6183400B2 (ja) * | 2015-03-31 | 2017-08-23 | コニカミノルタ株式会社 | 契約書作成プログラム、契約書検証プログラム、最終暗号作成プログラム、契約書作成システム、契約書検証システム及び最終暗号作成システム |
KR101831134B1 (ko) * | 2016-05-17 | 2018-02-26 | 현대자동차주식회사 | 암호화를 적용한 제어기 보안 방법 및 그 장치 |
DE102016221108A1 (de) * | 2016-10-26 | 2018-04-26 | Volkswagen Aktiengesellschaft | Verfahren zum Aktualisieren einer Software eines Steuergeräts eines Fahrzeugs |
US9963106B1 (en) * | 2016-11-07 | 2018-05-08 | Nio Usa, Inc. | Method and system for authentication in autonomous vehicles |
DE102017129698A1 (de) | 2017-12-13 | 2019-06-13 | Endress+Hauser Conducta Gmbh+Co. Kg | Verfahren und System zum Betreiben einer Erweiterung an einem Messumformer der Prozessautomatisierungstechnik |
US11022971B2 (en) | 2018-01-16 | 2021-06-01 | Nio Usa, Inc. | Event data recordation to identify and resolve anomalies associated with control of driverless vehicles |
US20190302766A1 (en) * | 2018-03-28 | 2019-10-03 | Micron Technology, Inc. | Black Box Data Recorder with Artificial Intelligence Processor in Autonomous Driving Vehicle |
US10369966B1 (en) | 2018-05-23 | 2019-08-06 | Nio Usa, Inc. | Controlling access to a vehicle using wireless access devices |
US11804981B2 (en) * | 2021-01-14 | 2023-10-31 | Gm Global Technology Operations, Llc | Method and apparatus for providing an individually secure system to multiple distrusting parties |
Family Cites Families (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4930073A (en) * | 1987-06-26 | 1990-05-29 | International Business Machines Corporation | Method to prevent use of incorrect program version in a computer system |
JP3550834B2 (ja) * | 1995-11-13 | 2004-08-04 | 株式会社デンソー | 自動車用電子制御装置のメモリ書換システム,自動車用電子制御装置及びメモリ書換装置 |
DE19605554C2 (de) * | 1996-02-15 | 2000-08-17 | Daimler Chrysler Ag | Einrichtung zum Prüfen von Funktionselementen fahrzeugelektrischer Anlagen |
JP3580333B2 (ja) * | 1996-04-10 | 2004-10-20 | 日本電信電話株式会社 | 暗号認証機能の装備方法 |
US5825877A (en) * | 1996-06-11 | 1998-10-20 | International Business Machines Corporation | Support for portable trusted software |
US6138236A (en) * | 1996-07-01 | 2000-10-24 | Sun Microsystems, Inc. | Method and apparatus for firmware authentication |
US6754712B1 (en) * | 2001-07-11 | 2004-06-22 | Cisco Techonology, Inc. | Virtual dial-up protocol for network communication |
US5844986A (en) * | 1996-09-30 | 1998-12-01 | Intel Corporation | Secure BIOS |
JPH10161934A (ja) * | 1996-11-27 | 1998-06-19 | Nissan Motor Co Ltd | 車両用制御装置のフラッシュメモリ書き換え装置 |
JPH10200522A (ja) * | 1997-01-08 | 1998-07-31 | Hitachi Software Eng Co Ltd | Icカード利用暗号化方法およびシステムおよびicカード |
US5844896A (en) * | 1997-02-26 | 1998-12-01 | U S West, Inc. | System and method for routing telephone calls |
JP3704904B2 (ja) * | 1997-08-08 | 2005-10-12 | 日産自動車株式会社 | 車両制御用メモリ書き換え装置 |
US5970147A (en) * | 1997-09-30 | 1999-10-19 | Intel Corporation | System and method for configuring and registering a cryptographic device |
JPH11215120A (ja) * | 1998-01-27 | 1999-08-06 | Fujitsu Ltd | 通信装置 |
FR2775372B1 (fr) * | 1998-02-26 | 2001-10-19 | Peugeot | Procede de verification de la coherence d'informations telechargees dans un calculateur |
JPH11265349A (ja) * | 1998-03-17 | 1999-09-28 | Toshiba Corp | コンピュータシステムならびに同システムに適用される機密保護方法、送受信ログ管理方法、相互の確認方法および公開鍵世代管理方法 |
JP4066499B2 (ja) * | 1998-03-26 | 2008-03-26 | 株式会社デンソー | 電子制御装置,電子制御システムおよび適合判断方法 |
US6748541B1 (en) * | 1999-10-05 | 2004-06-08 | Aladdin Knowledge Systems, Ltd. | User-computer interaction method for use by a population of flexibly connectable computer systems |
US6754832B1 (en) * | 1999-08-12 | 2004-06-22 | International Business Machines Corporation | Security rule database searching in a network security environment |
-
2000
- 2000-02-25 DE DE10008974A patent/DE10008974B4/de not_active Expired - Fee Related
-
2001
- 2001-01-22 ES ES01101343.0T patent/ES2530229T3/es not_active Expired - Lifetime
- 2001-01-22 EP EP01101343.0A patent/EP1128242B1/de not_active Expired - Lifetime
- 2001-02-08 JP JP2001032507A patent/JP4733840B2/ja not_active Expired - Lifetime
- 2001-02-26 US US09/792,053 patent/US6816971B2/en not_active Expired - Lifetime
Cited By (31)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE10141737C1 (de) * | 2001-08-25 | 2003-04-03 | Daimler Chrysler Ag | Verfahren zur sicheren Datenübertragung innerhalb eines Verkehrsmittels |
DE10143556A1 (de) * | 2001-09-06 | 2003-03-27 | Daimler Chrysler Ag | Fahrzeugmanagementsystem |
US6859718B2 (en) | 2002-03-23 | 2005-02-22 | Daimlerchrysler Ag | Method and apparatus for accepting data |
EP1346881A2 (de) | 2002-03-23 | 2003-09-24 | DaimlerChrysler AG | Verfahren und Vorrichtung zum Übernehmen von Daten |
DE10213165B3 (de) * | 2002-03-23 | 2004-01-29 | Daimlerchrysler Ag | Verfahren und Vorrichtung zum Übernehmen von Daten |
DE10237698A1 (de) * | 2002-08-15 | 2004-02-26 | Volkswagen Ag | Verfahren und Vorrichtung zur Übertragung von Daten |
US8549324B2 (en) | 2002-08-21 | 2013-10-01 | Audi Ag | Method for protecting a motor vehicle component against manipulations in a control device and control device |
DE10238094B4 (de) * | 2002-08-21 | 2007-07-19 | Audi Ag | Verfahren zum Schutz gegen Manipulationen in einem Steuergerät für mindestens eine Kfz-Komponente und Steuergerät |
DE10238094A1 (de) * | 2002-08-21 | 2004-03-11 | Audi Ag | Verfahren zum Schutz gegen Manipulationen in einem Steuergerät für mindestens eine Kfz-Komponente und Steuergerät |
US7092783B2 (en) | 2002-10-24 | 2006-08-15 | Siemens Aktiengesellschaft | Programming and operating method for a programmable industrial controller, in particular a CNC controller |
EP1413939A1 (de) * | 2002-10-24 | 2004-04-28 | Siemens Aktiengesellschaft | Programmier- und Betriebsverfahren für eine programmierbare industrielle Steuerung, insbesondere eine CNC-Steuerung |
DE10255805A1 (de) * | 2002-11-29 | 2004-06-09 | Adam Opel Ag | Verfahren zur Änderung der Programmierung eines Steuergerätes eines Kraftfahrzeuges |
DE10309507A1 (de) * | 2003-03-05 | 2004-09-16 | Volkswagen Ag | Verfahren und Einrichtung zur Wartung von sicherheitsrelevanten Programmcode eines Kraftfahrzeuges |
WO2004090695A1 (de) * | 2003-04-12 | 2004-10-21 | Daimlerchrysler Ag | Verfahren zur überprüfung der datenintegrität von software in steuergeräten |
WO2004095238A1 (de) * | 2003-04-19 | 2004-11-04 | Daimlerchrysler Ag | Verfahren zur sicherstellung der integrität und authentizität von flashware für steuergeräte |
US7584350B2 (en) | 2003-06-24 | 2009-09-01 | Bayerische Motoren Werke Aktiengesellschaft | Method for booting up software in the boot sector of a programmable read-only memory |
WO2004114131A1 (de) * | 2003-06-24 | 2004-12-29 | Bayerische Motoren Werke Aktiengesellschaft | Verfahren zum nachladen einer software in den bootsektor eines programmierbaren lesespeicher |
DE10332452B4 (de) * | 2003-07-17 | 2018-04-12 | Continental Teves Ag & Co. Ohg | Steuerungs- und Regelungsgerät in einem Kraftfahrzeug sowie Verfahren zum Betreiben desselben |
WO2005016708A1 (de) * | 2003-07-17 | 2005-02-24 | Continental Aktiengesellschaft | Steuerungs- und regelungsgerät in einem kraftfahrzeug sowie verfahren zum betreiben desselben |
WO2005093567A1 (de) * | 2004-03-09 | 2005-10-06 | Bayerische Motoren Werke Aktiengesellschaft | Aktualisierung und/oder erweiterung der funktionalität der ablaufsteuerung mindestens eines steuergeräts |
US7899558B2 (en) | 2004-03-09 | 2011-03-01 | Bayerische Motoren Werke Aktiengesellschaft | Updating and/or expanding the functionality of sequence control of at least one control unit |
DE102004036810A1 (de) * | 2004-07-29 | 2006-03-23 | Zf Lenksysteme Gmbh | Kommunikationsverfahren für wenigstens zwei Systemkomponenten eines Kraftfahrzeugs |
US8032878B2 (en) | 2005-07-20 | 2011-10-04 | Denso Corporation | Data reprogramming method and system |
DE102006040228A1 (de) * | 2006-08-28 | 2008-03-06 | Giesecke & Devrient Gmbh | Identifikationssystem |
WO2011051128A1 (de) * | 2009-10-30 | 2011-05-05 | Continental Automotive Gmbh | Verfahren zum betreiben eines tachographen und tachograph |
US8931091B2 (en) | 2009-10-30 | 2015-01-06 | Continental Automotive Gmbh | Method for operating a tachograph and tachograph |
DE102010015648A1 (de) * | 2010-04-20 | 2011-10-20 | Siemens Aktiengesellschaft | Messgerät und Messverfahren |
DE102010038179A1 (de) * | 2010-10-14 | 2012-04-19 | Kobil Systems Gmbh | Individuelle Aktualisierung von Computerprogrammen |
DE102010038179B4 (de) * | 2010-10-14 | 2013-10-24 | Kobil Systems Gmbh | Individuelle Aktualisierung von Computerprogrammen |
DE102015011920A1 (de) | 2015-09-03 | 2017-03-09 | Continental Automotive Gmbh | Verfahren zur Überprüfung der Datenintegrität einer C2C Übertragung |
DE102019206302A1 (de) * | 2019-05-02 | 2020-11-05 | Continental Automotive Gmbh | Verfahren und Vorrichtung zum Übertragen eines Boot-Codes mit verbesserter Datensicherheit |
Also Published As
Publication number | Publication date |
---|---|
ES2530229T3 (es) | 2015-02-27 |
DE10008974B4 (de) | 2005-12-29 |
EP1128242A3 (de) | 2006-01-18 |
US20020120856A1 (en) | 2002-08-29 |
US6816971B2 (en) | 2004-11-09 |
EP1128242A2 (de) | 2001-08-29 |
JP4733840B2 (ja) | 2011-07-27 |
JP2001255952A (ja) | 2001-09-21 |
EP1128242B1 (de) | 2015-01-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP1128242B1 (de) | Signaturverfahren | |
DE10008973B4 (de) | Autorisierungsverfahren mit Zertifikat | |
DE602005001351T2 (de) | Verteilte Verwaltung einer Zertifikatsrücknahmeliste | |
EP2936259B1 (de) | Aktualisieren eines digitalen geräte-zertifikats eines automatisierungsgeräts | |
EP1959606B1 (de) | Sicherheitseinheit | |
DE102016218986B4 (de) | Verfahren zur Zugriffsverwaltung eines Fahrzeugs | |
EP2689553B1 (de) | Kraftwagen-steuergerät mit kryptographischer einrichtung | |
DE10318031A1 (de) | Verfahren zur Sicherstellung der Integrität und Authentizität von Flashware für Steuergeräte | |
DE102007004645A1 (de) | Tachograph | |
EP3649768A1 (de) | Verfahren zum sicheren ersetzen eines bereits in ein gerät eingebrachten ersten herstellerzertifikats | |
DE102018101479A1 (de) | Steuerungsschnittstelle für ein autonomes fahrzeug | |
EP2235598B1 (de) | Feldgerät und verfahren zu dessen betrieb | |
EP1399797B1 (de) | Steuereinheit | |
EP3422628B1 (de) | Verfahren, sicherheitseinrichtung und sicherheitssystem | |
EP1741019A1 (de) | Authentisierung von steuergeräten in einem fahrzeug | |
EP3337085B1 (de) | Nachladen kryptographischer programminstruktionen | |
DE102012224194B4 (de) | Steuersystem für ein Kraftfahrzeug | |
EP3422274A1 (de) | Verfahren zur konfiguration oder änderung einer konfiguration eines bezahlterminals und/oder zur zuordnung eines bezahlterminals zu einem betreiber | |
WO2015180867A1 (de) | Erzeugen eines kryptographischen schlüssels | |
EP1740418B1 (de) | Authentisierung einer fahrzeugexternen vorrichtung | |
WO2013056740A1 (de) | Digitaler tachograph | |
EP1126655A1 (de) | Verfahren zur Authentizitätssicherung von Hard- und Software in einem vernetzten System | |
EP3114600A1 (de) | Sicherheitssystem mit Zugriffskontrolle | |
DE102009053230A1 (de) | Verfahren zur Autorisierung eines externen Systems auf einem Steuergerät eines Fahrzeugs, insbesondere eines Kraftfahrzeugs | |
EP3881486B1 (de) | Verfahren zur bereitstellung eines herkunftsortnachweises für ein digitales schlüsselpaar |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
OP8 | Request for examination as to paragraph 44 patent law | ||
8364 | No opposition during term of opposition | ||
R119 | Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee |