DE10008973B4 - Autorisierungsverfahren mit Zertifikat - Google Patents
Autorisierungsverfahren mit Zertifikat Download PDFInfo
- Publication number
- DE10008973B4 DE10008973B4 DE10008973A DE10008973A DE10008973B4 DE 10008973 B4 DE10008973 B4 DE 10008973B4 DE 10008973 A DE10008973 A DE 10008973A DE 10008973 A DE10008973 A DE 10008973A DE 10008973 B4 DE10008973 B4 DE 10008973B4
- Authority
- DE
- Germany
- Prior art keywords
- key
- control unit
- certificate
- software
- vehicle
- 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.)
- Expired - Fee Related
Links
Classifications
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B60—VEHICLES IN GENERAL
- B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
- B60R25/00—Fittings or systems for preventing or indicating unauthorised use or theft of vehicles
- B60R25/20—Means to switch the anti-theft system on or off
- B60R25/24—Means to switch the anti-theft system on or off using electronic identifiers containing a code not memorised by the user
-
- 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/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- 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/3263—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 certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
-
- 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
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2145—Inheriting rights or properties, e.g., propagation of permissions or restrictions within a hierarchy
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Computing Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Mechanical Engineering (AREA)
- Storage Device Security (AREA)
- Lock And Its Accessories (AREA)
- Stored Programmes (AREA)
- Combined Controls Of Internal Combustion Engines (AREA)
Abstract
Verfahren zur Sicherstellung der Datenintegrität einer Software für ein Steuergerät eines Kraftfahrzeugs, in dem in einem Speicher eine das Steuergerät in seiner Wirkungsweise beeinflussende Software speicherbar ist, gekennzeichnet durch die Schritte:
Bereitstellen eines Steuergeräte-Schlüsselpaares mit einem ersten und einem zweiten Schlüssel,
Bereitstellen einer bestimmten Anzahl n von Zertifikats-Schlüsselpaaren mit jeweils einem ersten und einem zweiten Schlüssel,
Hinterlegen des ersten Schlüssels des Steuergeräte-Schlüsselpaares im oder für das Steuergerät in dem Kraftfahrzeug,
Erstellen von der bestimmten Anzahl n entsprechenden Zertifikaten, wobei jedes Zertifikat eine Zertifikatsinformation umfaßt, in der Zertifikatsinformation des letzten Zertifikates zumindest ein Schlüssel zur Überprüfung der Software und – falls mehrere Zertifikate verwendet werden – in den anderen Zertifikatsinformationen zumindest ein Schlüssel zur Überprüfung des nachfolgenden Zertifikates abgelegt sind,
Signieren der Zertifikatsinformation des ersten Zertifikates mit dem zweiten Schlüssel des Steuergeräte-Schlüsselpaares und – falls mehr als 1 Zertifikat vorhanden sind – Signieren der übrigen Zertifikate...
Bereitstellen eines Steuergeräte-Schlüsselpaares mit einem ersten und einem zweiten Schlüssel,
Bereitstellen einer bestimmten Anzahl n von Zertifikats-Schlüsselpaaren mit jeweils einem ersten und einem zweiten Schlüssel,
Hinterlegen des ersten Schlüssels des Steuergeräte-Schlüsselpaares im oder für das Steuergerät in dem Kraftfahrzeug,
Erstellen von der bestimmten Anzahl n entsprechenden Zertifikaten, wobei jedes Zertifikat eine Zertifikatsinformation umfaßt, in der Zertifikatsinformation des letzten Zertifikates zumindest ein Schlüssel zur Überprüfung der Software und – falls mehrere Zertifikate verwendet werden – in den anderen Zertifikatsinformationen zumindest ein Schlüssel zur Überprüfung des nachfolgenden Zertifikates abgelegt sind,
Signieren der Zertifikatsinformation des ersten Zertifikates mit dem zweiten Schlüssel des Steuergeräte-Schlüsselpaares und – falls mehr als 1 Zertifikat vorhanden sind – Signieren der übrigen Zertifikate...
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 Sicherheit gestellt werden müssen.
- In den verschiedensten Bereichen des Fahrzeugs werden Mikrocontroller zur Steuerung eingesetzt. Diese Steuergeräte sind heutzutage oft über ein oder mehrere Bussysteme 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 maskenprogrammierten Mikrocontrollern). Dadurch ist eine Manipulation der Software nicht ohne weiteres zu realisieren. Beispielsweise kann der komplette Austausch eines Speicherbausteins gegen einen anderen Speicherbaustein erkannt und entsprechend 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 Aufwand 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 Originalsoftware verhindern oder eine solche Änderung nur autorisierten Personen zugestehen.
- 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 einer unterschiedlichen Software. Bei diesem Konzept besteht freilich die Notwendigkeit, daß eine bestimmte Software 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 Public-Key-Verfahren mit einem öffentlichen und einem geheimen Schlüssel eine Authentifizierung und Überprüfung einer BIOS-Änderung durch. Dabei erfolgt die Überprüfung durch eine Prüfung einer in der einzuspielenden 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 umfaß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 Überprüfung einer in ein Steuergerät eines Kraftfahrzeuges einzuspielenden Software möglich.
- In der
EP 0 813 132 ist ein Authentifizierungsverfahren beschrieben, bei dem ein Programm mit einem Zertifikat und einer Zugangsliste gekoppelt ist. Gemäß einer bevorzugten Ausführungsform erstellt eine Zertifikat-Agentur ein Zertifikat für einen Code und ein Zertifikat für die Zugangsliste. Ist das Zertifikat einmal vergeben, ist es nicht mehr möglich, den Code oder die Zugangsliste zu verändern, ohne das Zertifikat zu verletzen. Der Code und die Zugangsliste werden zusammen mit ihren Zertifikaten in einem Server gespeichert. Mit diesem Verfahren kann ein Kunde, der den Code oder die Zugangsliste anfordert, deren Authentität feststellen. Eine Anwendung dieses Verfahrens im Kraftfahrzeugbereich ist jedoch nicht ohne weiteres möglich. - Aus der
DE 197 47 827 A1 ist ein Verfahren und eine Einrichtung zur Einbringung eines Dienstschlüssels in einem Endgerät bekannt. Dabei wird von einer Zentrale ein verschlüsselt übertragener Dienstschlüssel an das Endgerät übermittelt. Im Endgerät erfolgt eine Entschlüsselung, wobei diese auf einem Codierungs/Decodierungsschlüssel-Paar basiert, welches durch einen Wirkungsgleich in der Zentrale und im Endgerätprogrammiergerät implementierten Algorithmus generierbar ist. - In der
DE 198 20 605 A1 ist ein Verfahren zur sicheren Verteilung von Software beschrieben, bei dem die Software signiert wird und die Signatur der Software in einem Terminal oder einer Chipkarte überprüft wird. Insbesondere wird dabei ein Hash-Wert erzeugt, der nach der Entschlüsselung mit einem nochmals generierten Hash-Wert übereinstimmen muss. - Allgemein wäre es von Vorteil, auf mehrere Berechtigte zur Erstellung und authentischen Kennzeichnung von angeforderter Software zurückgreifen zu können. Damit müßte die Kennzeichnung nicht von einer zentralen Stelle alleine vorgenommen werden. Allerdings sollte weiter eine zentrale Überwachungsstelle zur Berechtigungsvergabe für ausgewählte Berechtigte eingerichtet sein.
- Aufgabe der vorliegenden Erfindung ist es, ein Verfahren zur Sicherstellung der Datenintegrität einer Software für ein Steuergerät eines Kraftfahrzeugs zur Verfügung zu stellen, wobei mehrere Berechtigte, die von einer zentralen Einrichtung kontrollierbar sind, eine authentische Software erstellen und entsprechend kennzeichnen können.
- Die Aufgabe wird durch die Merkmale im Anspruch 1 gelöst.
- Demgemäß kann eine zentrale Einrichtung, nachfolgend als Trust-Center bezeichnet, an Berechtigte ein oder mehrere Zertifikate vergeben, mit dem der oder die damit Ausgestatteten Software für ein Steuergerät selbst ordnungsgemäß signieren und lauffähig in ein Fahrzeug einspielen können.
- Zu diesem Zweck stellt beispielsweise das Trust-Center (in einer alternativen Ausführungsform das Fahrzeug selbst) ein Steuergeräte-Schlüsselpaar mit einem ersten und einem zweiten Schlüssel bereit. Der erste Schlüssel wird bei der Produktion eines Fahrzeugs in dem Steuergerät selbst abgelegt oder für das Steuergerät hinterlegt. Aus diesem Grunde wird dieses Schlüsselpaar als Steuergeräte-Schlüsselpaar bezeichnet. Mit dem zweiten Schlüssel des Trust-Centers wird ein erstes Zertifikat für einen Berechtigten, nachfolgend Zertifikatsinhaber, signiert.
- Zur besseren Klarheit wird zunächst angenommen, daß nur ein Zertifikat zum lauffähigen Einlesen einer neuen Software in ein Steuergerät benötigt wird. Dieses eine Zertifikat enthält in einem Zertifikationsinformationsteil neben bestimmten Zertifikatsinformationen zumindest einen ersten Schlüssel des Zertifikatsinhabers, der sich selbst ein Zertifikats-Schlüsselpaar mit einem ersten und einem zweiten Schlüssel generiert hat. Als weitere Zertifikationsinformationen können beispielsweise der Zertifikatsaussteller, eine Seriennummer, der Zertifikatsinhaber, bestimmte Zugriffsrechte oder ein Gültigkeitszeitraum festgelegt sein.
- Der Berechtigte oder Zertifikatsinhaber signiert dann mit seinem zweiten Schlüssel des Zertifikats-Schlüsselpaares die in das Steuergerät einzuspielende Software. Sowohl das Zertifikat wie auch die von dem Zertifikatsinhaber signierte Software werden dann in das Steuergerät eines Fahrzeugs eingespielt. Das Steuergerät erkennt mittels seines eigenen ersten Schlüssels des Steuergeräte-Schlüsselpaares die Rechtmäßigkeit des Zertifikates und akzeptiert die Zertifikatsinformationen, darunter den darin enthaltenen Schlüssel. Mit diesem Schlüssel, also dem ersten Schlüssel des Zertifikats-Schlüsselpaares, wird wiederum die Überprüfung der Signatur der eingespielten Software vorgenommen. Ist auch diese Signatur als einwandfrei erkannt, so wird sie vom Steuergerät akzeptiert.
- Mit dieser Vorgehensweise kann man Änderungs- und Signierrechte allgemein vergeben. Es muß nicht jede Software von dem Inhaber des Steuergeräte-Schlüsselpaares, beispielsweise dem Trust-Center, selbst signiert werden. Mit den Zusatzinformationen im Zertifikat ist es darüber hinaus möglich, dem Zertifikatsinhaber eine Fülle von Zugeständnissen oder Beschränkungen zuzuweisen. Beispielsweise kann ein Zeitraum zugestanden werden, über den hinweg der Zertifikatsinhaber Software erstellen und einspielen kann. Es können verschiedene Berechtigungslevel für die Generierung von Software und die Art der Software vergeben werden. Die Signierung der Software selbst findet jedoch immer durch den Zertifikatsinhaber selbst statt.
- Unter Schlüssel versteht man allgemein Codier- und/oder Decodierparameter, die bei an sich bekannten kryptographischen Algorithmen verwendet werden. Dabei ist die Verwendung von symmetrischen und asymmetrischen Verfahren möglich. Bei symmetrischen Verfahren sind beide Schlüssel identisch, so daß eigentlich nur ein Schlüssel an verschiedenen Orten vorhanden ist. Bei asymmetrischen Verfahren werden verschiedene Schlüssel verwendet. Allgemein bekannt als asymmetrische Verfahren ist das Public-Key-Verfahren, bei dem ein öffentlicher und ein geheimer (privater) Schlüssel erzeugt werden. Der öffentlichen Schlüssel darf jedermann bekannt sein. Solche kryptographischen Algorithmen sind beispielsweise Rivest, Shamir und Adleman (RSA-Algorithmus), Data Encryption Algorithmus (DEA-Algorithmus) und dergleichen Algorithmen, bei denen es sich um asymmetrische Verfahren handelt. Diese Algorithmen können sowohl für das erste als auch für das zweite Schlüsselpaar verwendet werden.
- In einer komplexeren Ausgestaltung des vorliegenden erfindungsgemäßen Verfahren werden zur Überprüfung einer in ein Steuergerät eingespielten Software nicht nur ein einziges sondern mehrere Zertifikate n vergeben. Damit bestehen noch weitere Gestaltungsmöglichkeiten. Zum einen ist es möglich, verschiedene Zertifikate auf verschiedene Personen zu verteilen, so daß nur in Gemeinschaft ein lauffähiges Einspielen von neuer Software in ein Steuergerät möglich ist. Zudem ist es möglich, verschiedene Zugriffsrechte über die verschiedene Anzahl von Zertifikaten zu vergeben.
- Bei der Verwendung von mehreren Zertifikaten, kann die Signatur des ersten Zertifikates mit dem im Steuergerät hinterlegten Schlüssel geprüft werden. Die Signatur eines jeden weiteren Zertifikates kann wiederum von dem in einem vorherigen ak zeptierten Zertifikat enthaltenen Schlüssel überprüft werden. Mit dem Schlüssel im letzten Zertifikat wiederum wird schließlich die Signatur der Software selbst überprüft. Nur wenn alle Überprüfungen erfolgreich verlaufen sind, wird die Software vom Steuergerät akzeptiert. Damit die Signatur eines Zertifikates mit dem in einem vorherigen Zertifikat enthaltenen Schlüssel überprüft werden kann, muß es mit dem zweiten dazugehörigen Schlüssel signiert worden sein.
- Bei der Wahl, wo die geheimen und die öffentlichen Schlüssel jeweils abgelegt werden sollen, besteht eine große Variationsmöglichkeit. Beispielsweise sind in den Zertifikatsinformationen eines Zertifikates jeweils die öffentlichen Schlüssel abgelegt. Auch im Steuergerät selbst kann der öffentliche Schlüssel des Steuergeräte-Schlüsselpaares abgelegt sein. Entsprechend muß dann die zu überprüfende Signatur mit dem dazugehörigen geheimen Schlüssel gebildet worden sein.
- Natürlich sind auch andere Ausführungsformen denkbar, bei denen in der Zertifikatsinformation und/oder im Steuergerät selbst der geheime Schlüssel hinterlegt sind. Auch Kombinationen mit symmetrischen Schlüsseln sind durchaus denkbar.
- Vorzugsweise ist der im Steuergerät hinterlegte Schlüssel im Boot-Sektor abgelegt. Dieser ist normalerweise in besonderer Weise geschützt. Zur Erhöhung der Sicherheit, kann der Boot-Sektor auch so ausgebildet sein, daß er nach dem Beschreiben und dem Ablegen des darin enthaltenen Schlüssels „abgesperrt" wird, d.h. für zukünftige Zugriffe, insbesondere Schreibzugriffe gesperrt wird.
- Verlaufen alle Prüfungen positiv (Zertifikatsprüfung und Softwareprüfung), so wird die Software vom Steuergerät oder einer eigens dafür vorgesehenen Einrichtung akzeptiert und kann zur Steuerung des Steuergerätes herangezogen werden.
- Wie bereits oben beschrieben darf der öffentliche Schlüssel bei den sogenannten Public-Key-Verfahren öffentlich bekannt sein, wogegen der geheime Schlüssel nur einer autorisierten Stelle bekannt ist.
- Gemäß einer besonderen Ausführungsform ist der geheime Schlüssel des Steuergeräte-Schlüsselpaares nur dem Trust-Center und der geheime Schlüssel eines Zertifikats-Schlüsselpaares nur dem Zertifikatsinhaber bekannt. Mit jedem geheimen Schlüssel läßt sich – analog zur handschriftlichen Unterschrift – eine digitale Signatur zu einem elektronischen Dokument (Zertifikat, Software) erzeugen. Nur der Besitzer des geheimen Schlüssels kann eine jeweils gültige Signatur erstellen. Die Echtheit des Dokuments (Zertifikat, Software) kann über die Verifikation der Unterschrift mittels des öffentlichen Schlüssels überprüft werden. Ein nicht autorisierter Dritter, der den geheimen Schlüssel nicht kennt, ist nicht in der Lage, eine gültige Signatur zu erstellen. Wird ein manipuliertes, abgelaufenes oder nicht berechtigendes Zertifikat in ein Steuergerät geladen oder eine manipulierte und nicht richtig unterzeichnete Software in das Steuergerät geladen, so wird dies mit dem jeweils dazugehörigen Schlüssel erkannt und das Steuergerät wird in einen nichtlauffähigen Zustand versetzt.
- Bei der Verwendung eines symmetrischen Verfahren kann zur Erhöhung der Sicherheitsstufe ein zusätzlicher Auslöseschutz in Form einer speziellen Hardware herangezogen werden.
- Um die Anforderungen eines ausschließlich fahrzeugindividuellen Einsatzes einer Software zu ermöglichen, enthält die für ein Steuergerät eines bestimmten Fahrzeugs vorgesehene Software fahrzeugindividualisierende Informationen, beispielsweise die Fahrgestellnummer oder andere fahrzeugindividuelle Daten. Diese Informationen sind der Software zugeordnet oder in diese integriert. Erst nach der Zuordnung oder Integration dieser Daten zur bzw. in die Software wird diese dann mit dem zweiten Schlüssel des Zertifikatsinhabers des letzten Zertifikates signiert. Ein Steuergerät akzeptiert – wie oben beschrieben – nur dann die Software, wenn zum einen das oder die Zertifikate und außerdem die Signatur der Software als einwandfrei erkannt worden sind. Da die Signatur von der in der Software enthaltenen fahrzeugindividuellen Information abhängt, kann diese nicht nachträglich verändert werden. Es kann nur eine Software lauffähig für ein Steuergerät eines Fahrzeugs eingespeist werden, wenn die fahrzeugindividuelle Information nicht verändert ist und mit derjenigen des Fahrzeugs tatsächlich übereinstimmt. Ein Kopieren einer solch individualisierten Software auf ein anderes Fahrzeug ist damit unmöglich.
- Um eine weitere Sicherheitsstufe beim Einspielen von Software in den Speichern des Steuergerätes zu schaffen, sollte zudem vor dem Einspielen der Software ein Zugang zum Speicher des Steuergerätes nur mit entsprechender Berechtigung möglich sein. Dazu ist vor dem Überspielen der signierten Software ein „Aufschließen" des Steuergerätes in einem Anmeldeschritt vorgesehen. Bei der Verwendung unterschiedlicher priorisierter Level bei der Anmeldung könnten überdies auch verschieden ausgestaltete Zugriffsrechte vergeben werden. Bei einem Diagnosezugriff wäre beispielsweise zunächst eine Anmeldung notwendig, wodurch das Steuergerät über die eingegebene Zugangsinformation die Zugriffsrechte und die damit verbundene Berechtigungsstufe erkennt. Je nach Rechtevergabe können die Zugriffsberechtigungen von unkritisch bis sehr kritisch eingestuft werden. Die Rechtevergabe kann statisch gestaltet sein, so daß beispielsweise verschiedene Zugangscodes für bestimmte Berechtigungsstufen ausgegeben werden. Alternativ kann die Rechtevergabe auch dynamisch gestaltet werden, so daß beispielsweise Zutrittszertifikate vergeben werden, in deren Zertifikatsinformation die Berechtigungsstufe enthalten ist.
- Gemäß einer Alternative werden die Überprüfungen der Signaturen im Steuergerät selbst durchgeführt. Gemäß einer weiteren Alternative kann zumindest eine Überprüfung auch in einer eigenen Zutritts- bzw. Zugriffssteuerung überprüft werden. Ein evtl. ausschließlich für die Zugriffssteuerung vorgesehenes Steuergerät sollte im Vergleich zu den übrigen Steuergeräten wegen der zentralen Sicherheitsfunktion hinsichtlich der Vergabe von Zugriffsrechten nicht zugänglich im Kraftfahrzeug angeordnet sein, da durch den physikalischen Ausbau eines Steuergerätes die oben beschriebenen Schutzmechanismen evtl. umgangen werden könnten.
- Um ferner auch die Gefahr auszuschließen, daß ein Steuergerät ganz ausgebaut und gegen ein anderes ersetzt wird, kann zusätzlich ein Steuergeräteausbauschutz 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 ab und zu eine Anfrage an jedes Steuergerät gerichtet, die diese mit einer bestimmten erwarteten Information beantworten müssen. Stimmt die tatsächlich von einem zu überprüfenden Steuergerät abgegebene Information nicht mit der erwarteten Information überein oder antwortet das Steuergerät nicht, so werden geeignete Sicherungsmaßnahmen ergriffen. Beispielsweise wird das Steuergerät aus dem Kommunikationsverbund ausgeschlossen oder das Steuergerät wird registriert, markiert oder in eine Liste aufgenommen. Bei einer Diagnose des Fahrzeugs kann die Manipulation dann erkannt werden. Bei der oben beschriebenen Ausführungsform antworten die Steuergeräte auf Anfrage beispielsweise mittels eines geheimen, steuergerätespezifischen Authentifikationsschlüssel. Ein illegal ausgetauschtes Steuergerät verfügt über einen solchen Schlüssel nicht und wird damit auch nicht akzeptiert.
- Die vorliegende Erfindung wird nachfolgend anhand von Ausführungsbeispielen und mit Bezug auf die beiliegenden Zeichnungen näher erläutert. Die Zeichnungen zeigen in
-
1 eine schematische Darstellung einer Steuergerätestruktur in einem Fahrzeug, -
2 ein Ablaufdiagramm für ein Einlesen von Software in ein Steuergerät und -
3 eine schematische Darstellung für den Ablauf zur Vergabe einzelner Signaturen damit eine Software einwandfrei ein Steuergerät steuern kann, -
4 eine schematische Darstellung für die Vergabe eines Zertifikates durch ein Trust-Center, -
5 eine schematische Darstellung für die Erstellung einer digitalen Signatur für eine Software, -
6 eine schematische Darstellung des Ablaufes der Überprüfungen in einem Steuergerät zur Verifikation von eingespielter Software, -
7a bis7d Darstellungen zur Verschlüsselung und Verifikation von Zertifikat und Software unter Verwendung eines Hash-Codes und -
8 eine Darstellung eines Algorithmus für eine Überprüfung von fahrzeugindividuellen Informationen. - In
1 ist blockdiagrammartig eine Steuergerätestruktur mit miteinander vernetzten Einheiten abgebildet. Das Boardnetz besteht hierbei aus mehreren Teilnetzen (LWL-Most, K-CAN System, Powertrain-CAN etc.), die zum Teil unterschiedliche Übertragungsgeschwindigkeiten besitzen und durch sogenannte Gateways (Zentrales Gateway Modul, Controller Gateway) miteinander verbunden sind. Mittels des Zentralen Gateways14 ist ein Diagnosebus16 mit allen übrigen Netzen mittelbar oder unmittelbar gekoppelt. Der Diagnosebus16 stellt eine der wichtigsten Verbindungen zur Umwelt dar. Über einen Diagnosetester, der an einer OBD-Steckdose (OBD = on board diagnose) am Ende des Diagnosebuses16 angeschlossen ist, und unter Zwischenschaltung des zentralen Gateways14 können sämtliche Controller, Gateway und Steuergeräte im gesamten System angesprochen werden. - Alternativ besteht die Möglichkeit, über das GSM-Netz
20 und ein Telefonsystem18 im Fahrzeug auf die Geräte im Fahrzeug zuzugreifen. Damit ist prizipiell ein Remotezugriff auf das Fahrzeug-Boardnetz möglich. Das Telefonsystem18 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 Wegfahrsperne. - Ein Mulitmedia-Changer (MMC) stellt eine Schnittstelle zwischen einem CD-Player und dem Bordnetz dar. Beim Controller Gateway
21 werden 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) dargestellt. Die Aufgabe eines Steuergerätes besteht nicht nur in der Steuerung einer bestimmten Einheit im Fahrzeug, sondern auch in der Kommunikation zwischen den Geräten selbst. Die Kommunikation im Fahrzeug ist vorliegend „Broadcast orientiert". Ein Erzeuger von Informationen, der den Buszugriff gewonnen hat, sendet seine Informationen 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 überwiegend in einem programmierbaren Flash-Speicher untergebracht. Bei einer Flashprogrammierung können nur ganze Blöcke gelöscht und neu beschrieben werden. Das Löschen einzelner Bites ist nicht möglich. Je nach Steuergeräten werden unterschiedliche Arten von Mikrocomputern eingesetzt. 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 Prozessor selbst integriert auf.
- Nachfolgend soll näher auf die vorliegend verwendete Verschlüsselung eingegangen werden. Bei dem verwendeten Authentifizierungsverfahren wird eine asynchrone Verschlüsselung bevorzugt. Bei symmetrischen Schlüsseln muß jede Seite im Besitz des Geheimnisses sein. Sobald ein synchroner Schlüssel bekannt ist, kann eine wirksame Verschlüsselung nicht mehr sichergestellt werden. Da ein Schlüssel des Schlüsselpaares 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üsselungsart wird ein Schlüsselpaar mit einem öffentlichen und einem geheimen Schlüssel erzeugt. Mit dem öffentlichen Schlüssel kann jeder entschlüsseln, es kann aber nicht verschlüsselt werden. Zum Verschlüsseln (signieren) hingegen wird der geheime Schlüssel benötigt.
- 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 Kommunikation wird dann mit dem symmetrischen Schlüssel verschlüsselt.
- Durch die Trennung von geheimen Schlüssel und öffentlichen Schlüssel lassen sich Authentifizierungsverfahren und digitale Signaturen wie oben beschrieben realisieren. Durch den Besitz des geheimen Schlüssels läßt sich eine Identität eindeutig nachweisen, und es kann eine Signatur, wie bei einer handschriftlichen Unterschrift erstellt werden. Bekannte Public-Key-Kryptosysteme sind das RSA-Verfahren. Andere Public-Key-Krypto-Verfahren beruhen auf Problemen in bestimmten mathematischen Gruppen, Logarithmen zu berechnen (Diskreter-Logarithmus-Problem).
- Die vorliegende Erfindung wird im folgenden anhand eines bestimmten Ausführungsbeispiels beschrieben, bei dem ein Kunde eine bestimmte zusätzliche Funktion in seinem Kraftfahrzeug wünscht. Beispielsweise soll das Getriebe mit anderen Schaltkennlinien betrieben werden. Diese Funktion kann durch die Einspielung neuer Software in ein Steuergerät seines Fahrzeugs realisiert werden. Zur Realisierung wendet sich der Kunde an eine autorisierte Stelle, beispielsweise einen Händler, die eine solche Software erstellen und ablauffähig in sein Fahrzeug einspielen kann.
- Die dafür notwendigen Abläufe werden im folgenden erläutert.
- Um nicht alle bestellten Softwareumfänge von einer einzigen Stelle abzeichnen (signieren) lassen zu müssen, werden zunächst mehrere dezentrale Berechtigte – sogenannte Zertifikatsinhaber – (z.B. Händler) aufgebaut, bei denen eine gewünschte Software bestellt werden kann. Durch die Vergabe von Zertifikaten wer den die Berechtigten in die Lage versetzt, die bestellte Software selbst zu erzeugen und auch zu unterzeichnen (signieren).
- Der Ablauf wird zunächst mit Bezug zur
3 näher erläutert. In einem Trust-Center (404 in4 ) wird ein erstes Schlüsselpaar300 mit einem privaten Schlüssel304 und einem öffentlichen Schlüssel302 erzeugt. - Ein Schlüssel ist dabei ein elektronischer Code, mit dem eine Information ver- und/oder entschlüsselt werden kann. Man verwendet dabei bekannte kryptographische Algorithmen, wie die bereits oben beschriebenen RSA oder DEA Algorithmen, also sogenannte „public-key-Algorithmen" mit asynchronen Schlüsselpaaren.
- Der öffentliche Schlüssel
302 des Trust-Centers wird bereits bei der Produktion eines Fahrzeugs in einem Steuergerät306 im Bootsektor308 abgelegt. - Mit dem privaten Schlüssel
304 jedoch wird nunmehr ein Zertifikat318 unterzeichnet (signiert), welches bestimmte Zertifikatinformationen enthält. - Der Zertifikatinhaber erstellt ebenfalls ein Schlüsselpaar
312 (zweites Schlüsselpaar) mit einem weiteren privaten314 und einem weiteren öffentlichen316 Schlüssel. Der öffentliche Schlüssel316 wird als eine Zertifikatsinformation im Zertifikat318 abgelegt. Weitere Zertifikatsinformationen können beispielsweise der Zertifikatsaussteller, die Seriennummer, der Zertifikatsinhaber, bestimmte Zugriffsrechte oder der Gültigkeitszeitraum sein. - Mit dem privaten Schlüssel
314 des Zertifikatsinhabers, der nur diesem bekannt ist, wird eine Software320 in nachfolgend noch zu beschreibender Weise signiert (Signatur322 ). Der Zertifikatsinhaber spielt sodann das ständig bei ihm vorhandene Zertifikat318 wie auch die erstellte und signierte Software320 in das Steuergerät306 ein. - Die weitere Vorgehensweise wird nun anhand von
6 erläutert. Das Steuergerät600 (Bezugszeichen306 in3 ) prüft bei seinem ersten Hochlauf nach der Einspielung zunächst, ob das Zertifikat618 einwandfrei ist. Dazu wird mittels dem im Bootsektor603 des Steuergerätes600 hinterlegten öffentlichen Schlüssels602 des Trust-Centers die Signatur 2619 des Zertifikates618 geprüft. Wird das Zertifikat618 für o.k. befunden (Ja), ist die darin gespeicherte Zertifikatsinformation617 zusammen mit dem öffentlichen Schlüssel616 ebenfalls akzeptiert. Ist das Zertifikat bzw. dessen Unterschrift619 nicht einwandfrei verifiziert (Nein), wird der Betrieb des Steuergerätes gestoppt (Stop). - Mit dem im Zertifikat
618 enthaltenen öffentlichen Schlüssel616 wiederum wird die Signatur 1608 der Software606 überprüft. Wird diese Prüfung ebenfalls bestanden (Ja), kann das Steuergerät mit der neu eingespielten Software610 betrieben werden (o.k.). Andernfalls (Nein) wird der Betrieb des Steuergerätes600 gestoppt (Stop). - Insgesamt kann mit der beschriebenen Vorgehensweise eine Dezentralisierung von berechtigten Stellen, welche zur Unterzeichnung von Software befugt sind, erreicht werden. Dabei stehen verschiedenste Möglichkeiten offen, im Zertifikat weitere Berechtigungen und Beschränkungen zu verpacken. Ist im Zertifikat ein Gültigkeitszeitraum enthalten, so kann ein vormaliger Zertifikatsinhaber nach dem Ablauf des Gültigkeitszeitraum keine Software mehr signieren bzw. diese Software wird nicht mehr akzeptiert, weil das Zertifikat nicht mehr akzeptiert wird. Zudem kann über den Inhaber des Zertifikates auch nachvollzogen werden, wer in einem Steuergerät eine Software eingelesen und somit eine Modifikation vorgenommen hat.
- In
2 ist eine weitere Sicherungsstufe dargestellt. Soll eine neue Software in ein Steuergerät eines Fahrzeugs eingespielt werden, so muß man sich zunächst anmelden (Schritt200 in2 ). Bei der Anmeldung erfolgt eine Identifizierung des Berechtigten. Erst bei erfolgreicher Identifizierung wird das Steuergerät „aufgesperrt" wodurch prinzipiell ein Einlesen von neuer Software und des Zertifikates in das Steuergerät möglich ist (Schritt202 in2 ). Erst nach dem Einlesen erfogt dann die oben beschriebene Verifikation des Zertifikates und der Software. - Im folgenden wird die Erstellung des Zertifikates näher beleuchtet. Zunächst muß zwischen dem Trust-Center und einem Dritten Einigkeit bestehen, daß dieser Dritte als Zertifikatinhaber eine gewisse Berechtigungsstufe zugesprochen bekommt, ge änderte Software in ein Steuergerät oder für ein Steuergerät eines Fahrzeugs einzulesen. Ist eine Einigung erzielt, generiert der zukünftige Zertifikatsinhaber (z.B. eine Werkstatt
400 ) sein eigenes Schlüsselpaar mit einem privaten und einem öffentlichen Schlüssel und sendet den öffentlichen Schlüssel mit einer Zertifikatsanforderung (Schritt402 in4 ) an das Trust-Center404 . - Das Trust-Center
404 erstellt das Zertifikat406 , signiert es mit dem geheimen Schlüssel (vgl. auch Bezugszeichen304 in3 ) und sendet es an den Zertifikatsinhaber400 zurück, wo es verbleibt. - Der Zertifikatsinhaber
400 kann ab Erhalt des Zertifikates und soweit ihm dies das Zertifikat406 erlaubt Software408 (auch Bezugszeichen320 in3 ) mit seinem privatem Schlüssel signieren. Dies ist in5 näher dargestellt. Dort wird eine Software500 in einer Einheit540 mit dem geheimen Schlüssel520 signiert. Die - signierte Software560 ist dann zum Einspielen in das Steuergerät eines Fahrzeuges bereit. Mit Bezug auf4 ist dies auch dargestellt. Dort wird die signierte Software408 sowie das Zertifikat406 von dem Zertifikatsinhaber in ein Fahrzeug12' eingespielt. - Mit Bezug auf die
7a bis7b wird das signieren der Software und des Zertifikates sowie die Überprüfung der jeweiligen Signatur näher erläutert. - Es ist ineffizient ein gesamtes elektronischen Dokument in seiner Gesamtheit zu signieren. Vielmehr wird dazu vorliegend eine sogenannte Hash-Funktion verwendet.
- Genauer gesagt wird aus der Software
750 über eine an sich bekannte Hash-Funktion ein sogenannter Hash-Code751 generiert, bei dem es sich um eine digitale Information mit vorgegebener Länge handelt. Dieser Hash-Code751 wird dann mit dem geheimen Schlüssel des Zertifikatsinhabers signiert (Signatur 1752 ). Die Signierung des Hash-Codes751 ist wesentlich effizienter als die Signatur von langen Software-Dokumenten. Die bekannten Hash-Funktionen haben dabei folgende wesentliche Eigenschaften: Es ist im allgemeinen 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). - Die angeforderte Software
753 kann – wie oben bereits erwähnt – vom Zertifikatsinhaber selbst erstellt und signiert werden. - In analoger Weise zur Software wird ein Zertifikat erstellt (
7b ). Aus der gesamten Zertifikatsinformation760 inklusive dem öffentlichen Schlüssel des Zertifikatsinhabers wird über eine gleiche oder eine andere Hash-Funktion ein weiterer Hash-Code761 generiert, bei dem es sich um eine digitale Information mit einer anderen vorgegebenen Länge handelt. Dieser andere Hash-Code761 wird dann mit dem geheimen Schlüssel des Trust-Centers signiert (Signatur 2762 ). - Nach dem Einspielen der neuen Software sowie des Zertifikates in ein Steuergerät wird dann beim nächsten Betrieb zunächst mittels des öffentlichen, im Steuergerät gespeicherten Schlüssels überprüft, ob die Signatur des Zertifikates einwandfrei ist (
7c ). Dazu wird der öffentliche Schlüssel aus dem Steuergerät auf die Signatur 2 angewendet, was einen berechneten Hash-Code (Bezugszeichen765 ) ergibt. Dieser berechnete Hash-Code765 wird in einem Komparator764 mit dem aus dem Zertifikat selbst nach der oben genannten Hash-Funktion gebildeten Hash-Code761' verglichen. Vorliegend stimmen beiden Hash-Codes765 und761' nicht miteinander überein. Das Zertifikat ist vorliegend unberechtigterweise verändert worden. Dadurch wird der Betrieb des Steuergerätes unterbunden (Stop). - Wäre das Zertifikat als einwandfrei verifiziert worden, so wird im nächsten Schritt (
7d ) überprüft, ob die Software ordnungsgemäß unterzeichnet ist. Dazu wird analog auf die Signatur1 der Software der öffentliche Schlüssel aus dem Zertifikat angewendet, wodurch ein Hash-Code756 bestimmt wird. Dieser Hash-Code756 wird mit dem direkt aus der Software bestimmten Hash-Code751' in einem Komparator754 verglichen. Vorliegend ist keine Übereinstimmung gegeben, so daß wiederum der Betrieb des Steuergerätes unterbunden werden würde. Würden die beiden Hash-Codes756 und751' jedoch übereinstimmen, so würde das Steuergerät mit der neuen Software betrieben werden können. Um eine Überprüfung bei jedem Hochlaufen zu verhindern, kann nach der ersten Verifikation auch ein Prüfbit ge setzt werden, welches eine einwandfreie Verifikation anzeigt. Natürlich darf ein solches Prüfbit nicht von außen modifizierbar sein. - Neben der oben beschriebenen digitalen Signatur wird zur Authentifikation eines Kommunikationspartners A gegenüber einem Kommunikationspartners B häufig ein sogenanntes Challenge-Response-Verfahren verwendet. Dabei sendet B zunächst eine Zufallszahl RANDOM 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.
- Nachfolgend wird anhand von
8 die Sicherstellung einer Individualisierung der Software für ein bestimmtes Fahrzeug beschrieben, wobei auf ein oben erwähntes Challenge-Response Verfahren Bezug genommen wird. - Das oben beschriebene Verfahren der Signatur einer Software wird insofern erweitert, als die Steuergeräte-Software noch für ein bestimmtes Fahrzeug individualisiert gekennzeichnet wird. Jede Software wird mit einem Identifikationsmerkmal eines bestimmten Fahrzeugs oder Fahrzeugtyps verbunden. Das Identifikationsmerkmal kann beispielsweise die Fahrgestellnummer sein.
- Nachfolgend wird beschrieben warum die so gekennzeichnete Software dann nur noch in dieses Fahrzeug bzw. diesen Fahrzeugtyp in funktionsfähiger Weise eingespielt werden kann.
- Zur Individualisierung der Software wird zunächst die Fahrgestellnummer FGNsw in die Software
800 eingetragen und anschließend wird die gesamte Software – zusammen mit einem privaten Schlüssel IFSp804 – wie oben beschrieben nach Erstellung des Hash-Codes signiert (Bezugszeichen802 ). Das Steuergerät806 akzeptiert wie bereits beschrieben nur eine korrekt signierte Software. Da die Fahrgestellnummer FGNsw den Hash-Code und die Signatur beeinflußt ist es nicht möglich, die Fahrgestellnummer nachträglich zu verändern. - Ist die Signatur
802 prinzipiell akzeptiert, wird überprüft, ob das der Software800 zugeorndete Fahrzeugidentifikationsmerkmal FGNsw mit dem tatsächlich im Fahr zeug vorliegenden Merkmal FGN übereinstimmt. Ist dies der Fall, wird die Software freigeschaltet. Damit kann die wie oben präparierte 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 solche Individualisierung einer Software durchführen zu können, sollte die Fahrgestellnummer bereits in der Fertigung in die entsprechenden Steuergeräte in nicht manipulierbarer Weise eingetragen werden. Die Fahrgestellnummer FGN muß auch nach einem Löschen eines Speichers in dem Steuergerät noch vorhanden sein. Dies kann dadurch realisiert werden, daß die Fahrgestellnummer beispielsweise in das oben bereits erwähnte Car-Access-System (CAS)
810 in einem nicht flüchtigen Speicher eingetragen ist. - Folgende Vorgehensweise gemäß
8 sichert dabei eine nicht manipulierbare Abfrage. Zusätzlich zur Fahrgestellnummer benötigt man ein weiteres fahrzeugindividuelles Schlüsselpaar bestehend aus einem geheimen Schlüssel IFSs und dem dem oben bereits erwähnten öffentlichen Schlüssel IFSp. Die Zuordnung der Fahrgestellnummer und der beiden Schlüssel erfolgt an zentraler Stelle. Der geheime Schlüssel IFSs ist in der Steuergeräteeinheit Car-Access-System (CAS)810 gespeichert und zwar in nicht auslesbarer Form. - Die Fahrgestellnummer FGN befindet sich bereits im Zugriffsbereich des Car-Access-Systems.
- In der neu einzuspielenden Software ist zusätzlich zur Fahrgestellnummer noch der öffentliche Schlüssel IFSp hinterlegt (
804 ). Danach wird die gesamte Software800 durch Signatur gesichert. Nach dem Laden der Software in das Steuergerät806 wird zunächst die Korrektheit der Signatur geprüft. Danach verifiziert das Steuergerät806 mittels einer vorher beschriebenen Challenge-Response-Abfrage, ob die Fahrgestellnummer in der Software mit der derjenigen des Fahrzeugs übereinstimmt. Dazu sendet das Steuergerät die Fahrgestellnummer aus der Software FGNsw und eine Zufallszahl RANDOM an das Car-Access-System810 (Bezugszeichen808 ). Dort wird die im Fahrzeug 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 Steuergerät806 zurück gesendet. Das Steuergerät806 kann nun mit dem öffentlichen Schlüssel IFSp die signierte Sendung überprüfen. Danach wird verglichen (Schritt814 ), ob die verschiedenen zueinander gehörenden Werte übereinstimmen. Ist dies der Fall (OK), so kann das Steuergerät806 mit der fahrzeugindividuellen Software betrieben werden. Verläuft der Vergleich negativ, so wird der Betrieb des Steuergerätes gestoppt (Schritt816 ). - Als Variante dieses Verfahren kann anstelle eines individuellen Schlüsselpaares IFSs und IFSp auch ein entsprechendes nicht für ein Fahrzeug individualisiertes Schlüsselpaar, das bereits im Fahrzeug gespeichert ist, verwendet werden. Dadurch entfällt die Verwaltung für diesen Schlüssel. Ebenso ist natürlich ein entsprechender Mechanismus mit einem symmetrischen kryptografischen Verfahren möglich. Dies hat zwar Vorteile bei der Abarbeitung, bringt aber die Gefahr des Auslesens des symmetrischen 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 Manipulationen vorzubeugen.
Claims (19)
- Verfahren zur Sicherstellung der Datenintegrität einer Software für ein Steuergerät eines Kraftfahrzeugs, in dem in einem Speicher eine das Steuergerät in seiner Wirkungsweise beeinflussende Software speicherbar ist, gekennzeichnet durch die Schritte: Bereitstellen eines Steuergeräte-Schlüsselpaares mit einem ersten und einem zweiten Schlüssel, Bereitstellen einer bestimmten Anzahl n von Zertifikats-Schlüsselpaaren mit jeweils einem ersten und einem zweiten Schlüssel, Hinterlegen des ersten Schlüssels des Steuergeräte-Schlüsselpaares im oder für das Steuergerät in dem Kraftfahrzeug, Erstellen von der bestimmten Anzahl n entsprechenden Zertifikaten, wobei jedes Zertifikat eine Zertifikatsinformation umfaßt, in der Zertifikatsinformation des letzten Zertifikates zumindest ein Schlüssel zur Überprüfung der Software und – falls mehrere Zertifikate verwendet werden – in den anderen Zertifikatsinformationen zumindest ein Schlüssel zur Überprüfung des nachfolgenden Zertifikates abgelegt sind, Signieren der Zertifikatsinformation des ersten Zertifikates mit dem zweiten Schlüssel des Steuergeräte-Schlüsselpaares und – falls mehr als 1 Zertifikat vorhanden sind – Signieren der übrigen Zertifikate mit dem jeweils zweiten Schlüssel eines Zertifikat-Schlüsselpaares, von dem der jeweils erste Schlüssel in der Zertifikatsinformation des vorhergehenden Zertifikat abgelegt ist, Signieren einer neu einzuspielenden Software mit dem zweiten Schlüssel eines Zertifikats-Schlüsselpaares, von dem der erste Schlüssel in der Zertifikatsinformation des letzten Zertifikats abgelegt ist, Einspielen aller signierten Zertifikate in das Steuergerät, Einspielen der signierten Software das Steuergerät, Überprüfen der Signatur des ersten Zertifikates mit dem im oder für das Steuergerät hinterlegten ersten Schlüssel des Steuergeräte-Schlüsselpaares und falls mehr als 1 Zertifikat vorhanden sind – Überprüfen der Signatur jeden weiteren Zertifikates mittels dem in der Zertifikatsinformation des vorhergehenden Zertifikat enthaltenen ersten Schlüssels, Akzeptieren der Zertifikatisinformation eines jeweiligen Zertifikates, wenn die jeweilige Überprüfung mit positivem Ergebnis verläuft, und Überprüfen der Signatur der Software mit dem in der Zertifikatsinformation des letztem Zertifikat hinterlegten ersten Schlüssel und Akzeptieren der eingespielten Software, wenn auch diese Überprüfung mit positivem Ergebnis verläuft.
- Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß in einem Zertifikat als die zumindest eine Zertifikatsinformation ein öffentlicher Schlüssel enthalten ist und daß die damit zu überprüfende Signatur mit einem zugehörigen geheimen Schlüssel durchgeführt ist.
- Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß der erste Schlüssel des Steuergeräte-Schlüsselpaares, der in dem oder für das Steuergerät hinterlegt ist, ein öffentlicher Schlüssel ist und die Signatur des ersten Zertifikates mit dem zugehörigen geheimen Schlüssel durchgeführt ist.
- Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß das Fahrzeug, insbesondere ein Steuergerät im Fahrzeug, ein asynchrones Schlüsselpaar mit einem öffentlichen und einem geheimen Schlüssel erzeugt, daß der geheime Schlüssel im Fahrzeug, insbesondere in einem Steuergerät, hinterlegt wird, und daß der öffentliche Schlüssel zur Signieren des ersten Zertifikates aus dem Fahrzeug auslesbar ist.
- Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß der im Steuergerät hinterlegte Schlüssel im Boot-Sektor des Steuergerätes abgelegt wird.
- Verfahren nach Anspruch 5, dadurch gekennzeichnet, daß der Boot-Sektor nach dem Beschreiben und der Eingabe des Schlüssel abgesperrt wird, und so gegen einen weiteren Zugriff, insbesondere einen Schreibzugriff, geschützt ist.
- Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die Software und/oder die Zertifikatsinformation jeweils auf eine Information mit bestimmter Länge abgebildet werden und diese Informationen dann signiert werden.
- Verfahren nach Anspruch 7, dadurch gekennzeichnet, daß als Abbildungsfunktion eine Hash-Funktion gewählt wird.
- 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 Signaturen der Zertifikate und 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.
- Verfahren nach Anspruch 9, dadurch gekennzeichnet, daß zur Überprüfung der fahrzeugindividuellen Information ein eigenes individuelles Schlüsselpaar erzeugt wird, wobei in einer Fahrzeugsicherheitseinheit oder dem Steuergerät die fahrzeugindividuelle Information und ein Schlüssel des fahrzeugindividuellen Schlüsselpaares vorhanden sind, in der Software neben der fahrzeugindividuellen Information noch der weitere Schlüssel des fahrzeugindividuellen Schlüsselpaares abgelegt ist und in einer separaten Routine überprüft wird, ob die beiden Schlüssel des fahrzeugindividuellen Schlüsselpaares zusammenstimmen, um bei einer Bejahung die eingespielte Software zu akzeptieren.
- Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die Software zumindest beim erstmaligem Hochlaufen des Steuergerätes geprüft und dann entsprechend gekennzeichnet wird.
- 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.
- Verfahren nach Anspruch 12, dadurch gekennzeichnet, daß ein Code von einem Steuergerät angefordert wird und der Code auf Richtigkeit hin geprüft wird.
- Verfahren nach Anspruch 13, dadurch gekennzeichnet, daß ein Steuergerät eine Zufallszahl ausgibt, die von dem Zugreifen zu signieren ist, und daß die Signatur im Steuergerät, insbesondere mittels eines Authetifizierungsschlüssels, überprüft wird.
- Verfahren nach einem der Ansprüche 12 bis 14, dadurch gekennzeichnet, daß bei der Abfrage der Zugriffsberechtigung eine Berechtigungsstufe festgestellt wird und Zugriffsaktionen in Abhängigkeit von der Berechtigungsstufe akzeptiert oder nicht akzeptiert werden.
- 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 Steuergerät bei negativem Ergebnis registriert.
- Verfahren nach Anspruch 16, dadurch gekennzeichnet, daß im Steuergerät ein steuergerätindividueller geheimer Code hinterlegt ist.
- Verfahren nach Anspruch 16 oder 17, dadurch gekennzeichnet, daß die Sicherheitseinrichtung ein steuergerätesprezifisches Merkmal abfrägt und dieses auf Authentität prüft.
- Verfahren nach einem der Ansprüche 16 bis 18, 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 (6)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE10008973A DE10008973B4 (de) | 2000-02-25 | 2000-02-25 | Autorisierungsverfahren mit Zertifikat |
EP01102165A EP1127756B1 (de) | 2000-02-25 | 2001-02-02 | Autorisierungsverfahren mit Zertifikat |
DE50105995T DE50105995D1 (de) | 2000-02-25 | 2001-02-02 | Autorisierungsverfahren mit Zertifikat |
ES01102165T ES2237500T3 (es) | 2000-02-25 | 2001-02-02 | Procedimiento de autorizacion con certificado. |
JP2001032508A JP2001255953A (ja) | 2000-02-25 | 2001-02-08 | 認可証を用いて権限を与える方法 |
US09/792,034 US7197637B2 (en) | 2000-02-25 | 2001-02-26 | Authorization process using a certificate |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE10008973A DE10008973B4 (de) | 2000-02-25 | 2000-02-25 | Autorisierungsverfahren mit Zertifikat |
Publications (2)
Publication Number | Publication Date |
---|---|
DE10008973A1 DE10008973A1 (de) | 2001-09-06 |
DE10008973B4 true DE10008973B4 (de) | 2004-10-07 |
Family
ID=7632445
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE10008973A Expired - Fee Related DE10008973B4 (de) | 2000-02-25 | 2000-02-25 | Autorisierungsverfahren mit Zertifikat |
DE50105995T Expired - Lifetime DE50105995D1 (de) | 2000-02-25 | 2001-02-02 | Autorisierungsverfahren mit Zertifikat |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE50105995T Expired - Lifetime DE50105995D1 (de) | 2000-02-25 | 2001-02-02 | Autorisierungsverfahren mit Zertifikat |
Country Status (5)
Country | Link |
---|---|
US (1) | US7197637B2 (de) |
EP (1) | EP1127756B1 (de) |
JP (1) | JP2001255953A (de) |
DE (2) | DE10008973B4 (de) |
ES (1) | ES2237500T3 (de) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE102007058975A1 (de) * | 2007-12-07 | 2009-06-10 | Bayerische Motoren Werke Aktiengesellschaft | Bordnetz eines Kraftfahrzeugs mit einem Master Security Modul |
DE102008008969A1 (de) * | 2008-02-13 | 2009-08-20 | Bayerische Motoren Werke Aktiengesellschaft | Bordnetz-System eines Kraftfahrzeugs mit einer Authentifizierungs-Vorrichtung |
Families Citing this family (92)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
FI108389B (fi) * | 1999-04-15 | 2002-01-15 | Sonera Smarttrust Oy | Tilaajaidentiteettimoduulin hallinta |
DE10102979C2 (de) * | 2001-01-10 | 2003-04-30 | Torsten Valentin | Verfahren zur Absicherung von Rechnern mit Anschluss an ein Netzwerk zum Zweck der Kontrolle von Netzwerkverbindungen |
DE10131578A1 (de) * | 2001-07-02 | 2003-01-16 | Bosch Gmbh Robert | Verfahren zum Schutz eines Mikrorechner-Systems gegen Manipulation von in einer Speicheranordnung abgelegten Daten |
DE10131575A1 (de) * | 2001-07-02 | 2003-01-16 | Bosch Gmbh Robert | Verfahren zum Schutz eines Mikrorechner-Systems gegen Manipulation von in einer Speicheranordnung des Mikrorechner-Systems gespeicherten Daten |
DE10141737C1 (de) * | 2001-08-25 | 2003-04-03 | Daimler Chrysler Ag | Verfahren zur sicheren Datenübertragung innerhalb eines Verkehrsmittels |
DE10140721A1 (de) * | 2001-08-27 | 2003-03-20 | Bayerische Motoren Werke Ag | Verfahren zur Bereitstellung von Software zur Verwendung durch ein Steuergerät eines Fahrzeugs |
DE10213658B4 (de) | 2002-03-27 | 2005-10-13 | Robert Bosch Gmbh | Verfahren zur Datenübertragung zwischen Komponenten der Bordelektronik mobiler Systeme und solche Komponenten |
DE10218050A1 (de) * | 2002-04-23 | 2003-11-13 | Zahnradfabrik Friedrichshafen | Verfahren zur Überwachung und Fehlerdiagnose für Komponenten des Antriebsstrangs eines Kraftfahrzeugs |
US20030217268A1 (en) * | 2002-05-15 | 2003-11-20 | Alexander Gantman | System and method for using acoustic digital signature generator as oracle |
US7127611B2 (en) * | 2002-06-28 | 2006-10-24 | Motorola, Inc. | Method and system for vehicle authentication of a component class |
US7076665B2 (en) * | 2002-06-28 | 2006-07-11 | Motorola, Inc. | Method and system for vehicle subassembly authentication of a component |
US7181615B2 (en) * | 2002-06-28 | 2007-02-20 | Motorola, Inc. | Method and system for vehicle authentication of a remote access device |
US20040001593A1 (en) * | 2002-06-28 | 2004-01-01 | Jurgen Reinold | Method and system for component obtainment of vehicle authentication |
US20040003230A1 (en) * | 2002-06-28 | 2004-01-01 | Puhl Larry C. | Method and system for vehicle authentication of a service technician |
US7137142B2 (en) * | 2002-06-28 | 2006-11-14 | Motorola, Inc. | Method and system for vehicle authentication of a component using key separation |
US7010682B2 (en) * | 2002-06-28 | 2006-03-07 | Motorola, Inc. | Method and system for vehicle authentication of a component |
US7137001B2 (en) * | 2002-06-28 | 2006-11-14 | Motorola, Inc. | Authentication of vehicle components |
US7131005B2 (en) * | 2002-06-28 | 2006-10-31 | Motorola, Inc. | Method and system for component authentication of a vehicle |
US7325135B2 (en) * | 2002-06-28 | 2008-01-29 | Temic Automotive Of North America, Inc. | Method and system for authorizing reconfiguration of a vehicle |
US20040003234A1 (en) * | 2002-06-28 | 2004-01-01 | Jurgen Reinold | Method and system for vehicle authentication of a subassembly |
US7600114B2 (en) * | 2002-06-28 | 2009-10-06 | Temic Automotive Of North America, Inc. | Method and system for vehicle authentication of another vehicle |
US7549046B2 (en) | 2002-06-28 | 2009-06-16 | Temic Automotive Of North America, Inc. | Method and system for vehicle authorization of a service technician |
US7228420B2 (en) * | 2002-06-28 | 2007-06-05 | Temic Automotive Of North America, Inc. | Method and system for technician 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 |
DE10237698A1 (de) * | 2002-08-15 | 2004-02-26 | Volkswagen Ag | Verfahren und Vorrichtung zur Übertragung von Daten |
US7401352B2 (en) * | 2002-08-30 | 2008-07-15 | International Business Machines Corporation | Secure system and method for enforcement of privacy policy and protection of confidentiality |
US7240200B2 (en) * | 2002-09-26 | 2007-07-03 | International Business Machines Corporation | System and method for guaranteeing software integrity via combined hardware and software authentication |
DE10245934A1 (de) * | 2002-09-30 | 2004-04-08 | Siemens Ag | Automatisierungssystem sowie Verfahren zu dessen Betrieb |
DE10255805A1 (de) * | 2002-11-29 | 2004-06-09 | Adam Opel Ag | Verfahren zur Änderung der Programmierung eines Steuergerätes eines Kraftfahrzeuges |
US6987922B2 (en) * | 2002-12-05 | 2006-01-17 | Tropic Networks Inc. | Method and apparatus for controlling a variable optical attenuator in an optical network |
DE10350647A1 (de) * | 2003-10-29 | 2005-06-09 | Francotyp-Postalia Ag & Co. Kg | Verfahren und Anordnung zur mobilen Datenübertragung |
CA2513909A1 (en) * | 2003-01-22 | 2004-08-05 | Francotyp-Postalia Ag & Co. Kg | Method and device for mobile data transmission |
JP2006521724A (ja) | 2003-01-28 | 2006-09-21 | セルポート システムズ インコーポレイテッド | セキュア・テレマティクス |
DE10309507A1 (de) * | 2003-03-05 | 2004-09-16 | Volkswagen Ag | Verfahren und Einrichtung zur Wartung von sicherheitsrelevanten Programmcode eines Kraftfahrzeuges |
EP1636700A1 (de) * | 2003-06-24 | 2006-03-22 | Bayerische Motoren Werke Aktiengesellschaft | 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 |
EP1642185A1 (de) * | 2003-07-04 | 2006-04-05 | Bayerische Motoren Werke Aktiengesellschaft | Verfahren zur authentifikation von einer insbesondere in ein steuergerät eines kraftfahrzeugs ladbaren softwarekomponente |
JP4714582B2 (ja) * | 2003-10-17 | 2011-06-29 | トリナリー・アンラーゲンバウ・ゲゼルシャフト・ミット・ベシュレンクテル・ハフツング | 工作機械の誤起動を防止するための方法 |
ATE383600T1 (de) | 2003-10-17 | 2008-01-15 | Trinary Anlagenbau Gmbh | Neutraldaten-computersteuerungssystem für eine werkzeugmaschine zur herstellung von werkstücken mit schraubenmantelfläche sowie eine zugehörige werkzeugmaschine |
US7346370B2 (en) * | 2004-04-29 | 2008-03-18 | Cellport Systems, Inc. | Enabling interoperability between distributed devices using different communication link technologies |
JP4621732B2 (ja) * | 2004-04-29 | 2011-01-26 | バイエリッシェ モートーレン ウエルケ アクチエンゲゼルシャフト | 車両外部の装置を認証するための方法、制御機器を有する自動車両のバスシステム及び車両外部の装置を認証するためのコンピュータ・プログラム |
DE102004024624B4 (de) * | 2004-05-18 | 2017-10-05 | Volkswagen Ag | Mit einer Verschlüsselung arbeitendes Verfahren zum Diebstahlschutz für ein Kraftfahrzeug und entsprechende Diebstahlschutzvorrichtung |
JP2005336911A (ja) * | 2004-05-28 | 2005-12-08 | Mitsubishi Electric Corp | 車両制御システム及びこれに用いる車載制御装置、携帯機 |
US20060020810A1 (en) * | 2004-07-24 | 2006-01-26 | International Business Machines Corporation | System and method for software load authentication |
US7660981B1 (en) * | 2004-11-30 | 2010-02-09 | Adobe Systems Incorporated | Verifiable chain of transfer for digital documents |
JP2006285849A (ja) * | 2005-04-04 | 2006-10-19 | Xanavi Informatics Corp | ナビゲーション装置 |
DE102005030657B3 (de) * | 2005-06-30 | 2006-11-16 | Siemens Ag | Codierverfahren und Codiereinrichtung zum Sichern eines Zählerstands eines Zählwerks vor einer nachträglichen Manipulation, sowie Prüfverfahren und Prüfeinrichtung zum Prüfen einer Authentizität eines Zählerstands eines Zählwerks |
ATE433596T1 (de) | 2005-08-23 | 2009-06-15 | Koninkl Philips Electronics Nv | Authentifizierung von informationsträgern über eine physische einwegfunktion |
US8004404B2 (en) | 2005-08-26 | 2011-08-23 | Mitsubishi Electric Corporation | Information storage device, information storage program, verification device and information storage method |
US8145917B2 (en) * | 2005-12-30 | 2012-03-27 | Nokia Corporation | Security bootstrapping for distributed architecture devices |
CA2677148C (en) * | 2007-02-02 | 2015-11-24 | Telcordia Technologies, Inc. | Method and system to authorize and assign digital certificates without loss of privacy |
CA2681502C (en) * | 2007-03-19 | 2013-07-23 | Telcordia Technologies, Inc. | Vehicle segment certificate management using shared certificate schemes |
US20080263644A1 (en) * | 2007-04-23 | 2008-10-23 | Doron Grinstein | Federated authorization for distributed computing |
DE102007022100B4 (de) * | 2007-05-11 | 2009-12-03 | Agco Gmbh | Kraftfahrzeugsteuergerätedatenübertragungssystem und -verfahren |
US8027293B2 (en) * | 2007-07-16 | 2011-09-27 | Cellport Systems, Inc. | Communication channel selection and use |
US8908870B2 (en) * | 2007-11-01 | 2014-12-09 | Infineon Technologies Ag | Method and system for transferring information to a device |
US8627079B2 (en) * | 2007-11-01 | 2014-01-07 | Infineon Technologies Ag | Method and system for controlling a device |
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 |
JP2009194443A (ja) * | 2008-02-12 | 2009-08-27 | Ntt Data Corp | 署名システム及び方法、ならびに、コンピュータプログラム |
DE102008050406A1 (de) * | 2008-10-04 | 2010-04-08 | Bayerische Motoren Werke Aktiengesellschaft | Datenübertragungsverfahren |
US8521547B2 (en) * | 2008-10-30 | 2013-08-27 | International Business Machines Corporation | Mechanic certification tracking validator |
DE102008043830A1 (de) * | 2008-11-18 | 2010-05-20 | Bundesdruckerei Gmbh | Kraftfahrzeug-Anzeigevorrichtung, Kraftfahrzeug-Elektroniksystem, Kraftfahrzeug, Verfahren zur Anzeige von Daten und Computerprogrammprodukt |
DE102009025585B4 (de) * | 2009-06-19 | 2012-08-16 | Audi Ag | Vorrichtung zur dezentralen Funktionsfreischaltung eines Steuergeräts |
US10383629B2 (en) | 2009-08-10 | 2019-08-20 | Covidien Lp | System and method for preventing reprocessing of a powered surgical instrument |
US8397063B2 (en) * | 2009-10-07 | 2013-03-12 | Telcordia Technologies, Inc. | Method for a public-key infrastructure for vehicular networks with limited number of infrastructure servers |
DE102009053230A1 (de) * | 2009-11-06 | 2011-05-12 | Bayerische Motoren Werke Aktiengesellschaft | Verfahren zur Autorisierung eines externen Systems auf einem Steuergerät eines Fahrzeugs, insbesondere eines Kraftfahrzeugs |
CN101938520B (zh) * | 2010-09-07 | 2015-01-28 | 中兴通讯股份有限公司 | 一种基于移动终端签名的远程支付系统及方法 |
WO2012043167A1 (ja) * | 2010-09-27 | 2012-04-05 | 日本電気株式会社 | 情報処理システム、車両のチェック方法、及び、車両のチェックプログラム |
JP5508216B2 (ja) * | 2010-10-05 | 2014-05-28 | 日本特殊陶業株式会社 | 車両用電装部品の制御装置およびその制御方法 |
US9420458B2 (en) | 2010-12-13 | 2016-08-16 | Volkswagen Ag | Method for the use of a mobile appliance using a motor vehicle |
DE102011014688B3 (de) | 2011-03-22 | 2012-03-22 | Audi Ag | Kraftwagen-Steuergerät mit kryptographischer Einrichtung |
US20130261927A1 (en) * | 2012-03-28 | 2013-10-03 | Delphi Technologies, Inc. | System and method to authenticate an automotive engine device |
EP2672414A1 (de) * | 2012-06-08 | 2013-12-11 | Sodge IT GmbH | Verfahren zur Übertragung von Konfigurationsdaten zu Steuerungsvorrichtungen, ein System und ein Computerprogrammprodukt |
US9292463B2 (en) * | 2012-09-26 | 2016-03-22 | Intel Corporation | Communication of device presence between boot routine and operating system |
US9179311B2 (en) * | 2013-10-04 | 2015-11-03 | GM Global Technology Operations LLC | Securing vehicle service tool data communications |
DE102014017513A1 (de) * | 2014-11-27 | 2016-06-02 | Audi Ag | Verfahren zum Betrieb eines Kraftfahrzeugs mit einem Diagnoseanschluss und Kraftfahrzeug |
JP5879451B1 (ja) * | 2015-04-20 | 2016-03-08 | 株式会社 ディー・エヌ・エー | 車両を管理するシステム及び方法 |
US10320745B2 (en) * | 2015-08-05 | 2019-06-11 | Samsung Electronics Co., Ltd. | Apparatus and method for transparent, secure element-based mediation of on-board diagnostic operations |
KR101673310B1 (ko) * | 2015-08-24 | 2016-11-07 | 현대자동차주식회사 | 인증서 기반의 차량 보안 접속 제어 방법 및 그를 위한 장치 및 시스템 |
DE102015220224A1 (de) | 2015-10-16 | 2017-04-20 | Volkswagen Aktiengesellschaft | Verfahren zur geschützten Kommunikation eines Fahrzeugs |
DE102016202527A1 (de) * | 2016-02-18 | 2017-08-24 | Robert Bosch Gmbh | Recheneinheit für ein Kraftfahrzeug |
US10728249B2 (en) * | 2016-04-26 | 2020-07-28 | Garrett Transporation I Inc. | Approach for securing a vehicle access port |
DE102016221108A1 (de) * | 2016-10-26 | 2018-04-26 | Volkswagen Aktiengesellschaft | Verfahren zum Aktualisieren einer Software eines Steuergeräts eines Fahrzeugs |
US10382562B2 (en) * | 2016-11-04 | 2019-08-13 | A10 Networks, Inc. | Verification of server certificates using hash codes |
US10530816B2 (en) * | 2017-05-18 | 2020-01-07 | Nio Usa, Inc. | Method for detecting the use of unauthorized security credentials in connected vehicles |
CN111247770B (zh) | 2017-09-29 | 2023-07-11 | 华为国际有限公司 | 一种使用ibc保护车辆外部通信的方法和相关系统 |
JP7065956B2 (ja) * | 2017-10-23 | 2022-05-12 | シーメンス アクチエンゲゼルシヤフト | 機器を制御および/またはモニターするための方法および制御システム |
DE102017222879A1 (de) * | 2017-12-15 | 2019-06-19 | Volkswagen Aktiengesellschaft | Vorrichtung, Verfahr, und Computerprogramm zum Freischalten von einer Fahrzeugkomponente, Fahrzeug-zu-Fahrzeug-Kommunikationsmodul |
DE102018217065A1 (de) * | 2018-10-05 | 2020-04-09 | Audi Ag | Steuervorrichtung zur Freischaltung zumindest einer Anwendungssoftware, Kraftfahrzeug und Verfahren zum Betreiben der Steuervorrichtung |
US11546176B2 (en) * | 2020-08-26 | 2023-01-03 | Rockwell Collins, Inc. | System and method for authentication and cryptographic ignition of remote devices |
DE102020006075A1 (de) | 2020-10-05 | 2022-04-07 | Daimler Ag | Verfahren zur Absicherung von gespeicherten Nutzdaten |
US11727733B2 (en) * | 2021-05-11 | 2023-08-15 | Ford Global Technologies, Llc | Enabling operator controls for machine operation |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0813132A2 (de) * | 1996-06-11 | 1997-12-17 | International Business Machines Corporation | Unterstützung für die Verteilung von vertrauter Software |
EP0816970A2 (de) * | 1996-07-01 | 1998-01-07 | Sun Microsystems, Inc. | Verfahren und Vorrichtung zur Authentifizierung von Firmwaren |
DE19747827A1 (de) * | 1997-02-03 | 1998-09-17 | Mannesmann Ag | Verfahren und Einrichtung zur Einbringung eines Dienstschlüssels in ein Endgerät |
US5844986A (en) * | 1996-09-30 | 1998-12-01 | Intel Corporation | Secure BIOS |
DE19820605A1 (de) * | 1998-05-08 | 1999-11-11 | Giesecke & Devrient Gmbh | Verfahren zur sicheren Verteilung von Software |
Family Cites Families (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5229648A (en) * | 1989-08-10 | 1993-07-20 | Autosafe International, Inc. | Multi element security system |
JP2942837B2 (ja) * | 1992-01-31 | 1999-08-30 | 株式会社セガ・エンタープライゼス | セキュリティチェック方法及びゲーム装置並びにそれらに用いられる情報記憶媒体 |
US5521815A (en) * | 1992-01-31 | 1996-05-28 | K.L.E. Irrevocable Trust | Uniform system for verifying and tracking articles of value |
US5689566A (en) * | 1995-10-24 | 1997-11-18 | Nguyen; Minhtam C. | Network with secure communications sessions |
US5883956A (en) * | 1996-03-28 | 1999-03-16 | National Semiconductor Corporation | Dynamic configuration of a secure processing unit for operations in various environments |
US5903882A (en) * | 1996-12-13 | 1999-05-11 | Certco, Llc | Reliance server for electronic transaction system |
JP3913823B2 (ja) * | 1997-02-10 | 2007-05-09 | 株式会社東海理化電機製作所 | 車両用始動許可装置 |
US5844896A (en) * | 1997-02-26 | 1998-12-01 | U S West, Inc. | System and method for routing telephone calls |
US6119226A (en) * | 1998-01-06 | 2000-09-12 | Macronix International Co., Ltd. | Memory supporting multiple address protocols |
JPH11282753A (ja) * | 1998-03-06 | 1999-10-15 | Internatl Business Mach Corp <Ibm> | オブジェクトへのアクセス方法及び装置、オブジェクトへのアクセスを制御するプログラムを格納した記憶媒体 |
JPH11265349A (ja) * | 1998-03-17 | 1999-09-28 | Toshiba Corp | コンピュータシステムならびに同システムに適用される機密保護方法、送受信ログ管理方法、相互の確認方法および公開鍵世代管理方法 |
US6138235A (en) * | 1998-06-29 | 2000-10-24 | Sun Microsystems, Inc. | Controlling access to services between modular applications |
US6105137A (en) * | 1998-07-02 | 2000-08-15 | Intel Corporation | Method and apparatus for integrity verification, authentication, and secure linkage of software modules |
US6463535B1 (en) * | 1998-10-05 | 2002-10-08 | Intel Corporation | System and method for verifying the integrity and authorization of software before execution in a local platform |
DE10008974B4 (de) * | 2000-02-25 | 2005-12-29 | Bayerische Motoren Werke Ag | Signaturverfahren |
US6490513B1 (en) * | 2001-08-22 | 2002-12-03 | Matsushita Electrical Industrial Co., Ltd. | Automobile data archive system having securely authenticated instrumentation data storage |
DE10141737C1 (de) * | 2001-08-25 | 2003-04-03 | Daimler Chrysler Ag | Verfahren zur sicheren Datenübertragung innerhalb eines Verkehrsmittels |
-
2000
- 2000-02-25 DE DE10008973A patent/DE10008973B4/de not_active Expired - Fee Related
-
2001
- 2001-02-02 EP EP01102165A patent/EP1127756B1/de not_active Expired - Lifetime
- 2001-02-02 ES ES01102165T patent/ES2237500T3/es not_active Expired - Lifetime
- 2001-02-02 DE DE50105995T patent/DE50105995D1/de not_active Expired - Lifetime
- 2001-02-08 JP JP2001032508A patent/JP2001255953A/ja active Pending
- 2001-02-26 US US09/792,034 patent/US7197637B2/en not_active Expired - Lifetime
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0813132A2 (de) * | 1996-06-11 | 1997-12-17 | International Business Machines Corporation | Unterstützung für die Verteilung von vertrauter Software |
EP0816970A2 (de) * | 1996-07-01 | 1998-01-07 | Sun Microsystems, Inc. | Verfahren und Vorrichtung zur Authentifizierung von Firmwaren |
US5844986A (en) * | 1996-09-30 | 1998-12-01 | Intel Corporation | Secure BIOS |
DE19747827A1 (de) * | 1997-02-03 | 1998-09-17 | Mannesmann Ag | Verfahren und Einrichtung zur Einbringung eines Dienstschlüssels in ein Endgerät |
DE19820605A1 (de) * | 1998-05-08 | 1999-11-11 | Giesecke & Devrient Gmbh | Verfahren zur sicheren Verteilung von Software |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE102007058975A1 (de) * | 2007-12-07 | 2009-06-10 | Bayerische Motoren Werke Aktiengesellschaft | Bordnetz eines Kraftfahrzeugs mit einem Master Security Modul |
DE102007058975B4 (de) | 2007-12-07 | 2022-10-06 | Bayerische Motoren Werke Aktiengesellschaft | Bordnetz eines Kraftfahrzeugs mit einem Master Security Modul |
DE102008008969A1 (de) * | 2008-02-13 | 2009-08-20 | Bayerische Motoren Werke Aktiengesellschaft | Bordnetz-System eines Kraftfahrzeugs mit einer Authentifizierungs-Vorrichtung |
DE102008008969B4 (de) | 2008-02-13 | 2022-07-14 | Bayerische Motoren Werke Aktiengesellschaft | Bordnetz-System eines Kraftfahrzeugs mit einer Authentifizierungs-Vorrichtung |
Also Published As
Publication number | Publication date |
---|---|
US7197637B2 (en) | 2007-03-27 |
DE10008973A1 (de) | 2001-09-06 |
DE50105995D1 (de) | 2005-06-02 |
ES2237500T3 (es) | 2005-08-01 |
US20020023223A1 (en) | 2002-02-21 |
JP2001255953A (ja) | 2001-09-21 |
EP1127756A2 (de) | 2001-08-29 |
EP1127756B1 (de) | 2005-04-27 |
EP1127756A3 (de) | 2004-04-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE10008973B4 (de) | Autorisierungsverfahren mit Zertifikat | |
DE10008974B4 (de) | Signaturverfahren | |
DE102012110499B4 (de) | Sicherheitszugangsverfahren für elektronische Automobil-Steuergeräte | |
DE602005001351T2 (de) | Verteilte Verwaltung einer Zertifikatsrücknahmeliste | |
EP2689553B1 (de) | Kraftwagen-steuergerät mit kryptographischer einrichtung | |
EP1959606B1 (de) | Sicherheitseinheit | |
EP2115703B1 (de) | Tachograph | |
DE102013205051A1 (de) | Aktualisieren eines digitalen Geräte-Zertifikats eines Automatisierungsgeräts | |
WO2005116834A1 (de) | Authentisierung von steuergeräten in einem fahrzeug | |
EP1399797B1 (de) | Steuereinheit | |
EP3422274A1 (de) | Verfahren zur konfiguration oder änderung einer konfiguration eines bezahlterminals und/oder zur zuordnung eines bezahlterminals zu einem betreiber | |
DE102012224194B4 (de) | Steuersystem für ein Kraftfahrzeug | |
EP1740418B1 (de) | Authentisierung einer fahrzeugexternen vorrichtung | |
WO2013056740A1 (de) | Digitaler tachograph | |
WO2018059964A1 (de) | Verfahren zum gesicherten zugriff auf daten eines fahrzeugs | |
EP1652337B1 (de) | Verfahren zum signieren einer datenmenge in einem public-key-system sowie ein datenverarbeitungssystem zur durchführung des verfahrens | |
DE102010004786A1 (de) | Verfahren zum rechnergestützten Bereitstellen einer Entwicklungsumgebung zur Implementierung von Sicherheitsanwendungen in einer Fahrzeug-Architektur | |
WO2006058828A2 (de) | Verfahren zur personalisierung von chipkarten | |
EP1642185A1 (de) | Verfahren zur authentifikation von einer insbesondere in ein steuergerät eines kraftfahrzeugs ladbaren softwarekomponente | |
EP1455312B1 (de) | Verfahren und Einrichtung zur Wartung von sicherheitsrelevanten Programmcode eines Kraftfahrzeuges | |
DE10238094A1 (de) | Verfahren zum Schutz gegen Manipulationen in einem Steuergerät für mindestens eine Kfz-Komponente und Steuergerät | |
DE102009053230A1 (de) | Verfahren zur Autorisierung eines externen Systems auf einem Steuergerät eines Fahrzeugs, insbesondere eines Kraftfahrzeugs | |
EP1533937B1 (de) | Verfahren zum Authentifizieren eines Gegenstands | |
EP1987466B1 (de) | Verfahren zur sicherstellung der hoheit über die aktivierung von anwendungen innerhalb eines sicherheitsmoduls | |
DE102007049151A1 (de) | Verfahren zur Durchführung einer automotiven Anwendung |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
OP8 | Request for examination as to paragraph 44 patent law | ||
8364 | No opposition during term of opposition | ||
8339 | Ceased/non-payment of the annual fee |