DE10141737C1 - Verfahren zur sicheren Datenübertragung innerhalb eines Verkehrsmittels - Google Patents

Verfahren zur sicheren Datenübertragung innerhalb eines Verkehrsmittels

Info

Publication number
DE10141737C1
DE10141737C1 DE2001141737 DE10141737A DE10141737C1 DE 10141737 C1 DE10141737 C1 DE 10141737C1 DE 2001141737 DE2001141737 DE 2001141737 DE 10141737 A DE10141737 A DE 10141737A DE 10141737 C1 DE10141737 C1 DE 10141737C1
Authority
DE
Germany
Prior art keywords
key
programs
public
program
computers
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
Application number
DE2001141737
Other languages
English (en)
Inventor
Viktor Friesen
Sebastian Schmar
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mercedes Benz Group AG
Original Assignee
DaimlerChrysler AG
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by DaimlerChrysler AG filed Critical DaimlerChrysler AG
Priority to DE2001141737 priority Critical patent/DE10141737C1/de
Application granted granted Critical
Publication of DE10141737C1 publication Critical patent/DE10141737C1/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • 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
    • 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
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
    • 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/321—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 a third party or a trusted authority
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer And Data Communications (AREA)
  • Storage Device Security (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zur Absicherung der Kommunikation zwischen Rechnern und Programmen in einem Verkehrsmittel, wobei die Rechner und Programme Daten mittels eines Datenbusses austauschen, der Datenaustausch verschlüsselt und/oder authentisiert stattfindet und kryptographische Schlüssel in den Rechnern und Programmen abgelegt werden. Die vorliegende Erfindung stellt ein Verschlüsselungsverfahren und ein Authentisierungsverfahren bereit, das ohne großen Aufwand durchführbar ist und ein sicheres Verfahren bei Datenbussystemen darstellt. Zudem ist das Verfahren derart gestaltet, dass nachgerüstete Komponenten in einfacher Weise in das Verschlüsselungsverfahren eingebunden werden können. Danach wird zur Absicherung der Kommunikation ein Public-Key-Verfahren herangezogen, wobei an dem Public-Key-Verfahren teilnehmenden Rechnern und/oder Programmen jeweils ein entsprechendes Schlüsselpaar, bestehend aus einem öffentlichen sowie einem privaten Schlüssel von einer Trust-Komponente, zugewiesen wird und die Trust-Komponente von einem der Rechner innerhalb des Verkehrsmittels gebildet wird.

Description

Die Erfindung betrifft ein Verfahren zur Absicherung der Kommu­ nikation zwischen Rechnern und Programmen in einem Verkehrsmit­ tel, wobei die Rechner und Programme Daten mittels eines Daten­ busses austauschen, der Datenaustausch verschlüsselt und/oder authentisiert stattfindet, kryptographische Schlüssel in den Rechnern und/oder Programmen abgelegt werden, wobei zur Absi­ cherung der Kommunikation ein Public-Key-Verfahren herangezogen wird, wobei an dem Public-Key-Verfahren teilnehmenden Rechnern und/oder Programmen jeweils ein entsprechendes Schlüsselpaar bestehend aus einem öffentlichen sowie einem privaten Schlüssel von einer Trust-Komponente zugewiesen wird, wobei die Trust- Komponente von einem der Rechner innerhalb des Verkehrsmittels gebildet wird.
Aus der DE 100 08 974 A1 ist ein Verfahren zur Sicherstellung der Datenintegrität einer Software für ein Steuergerät eines Kraftfahrzeugs bekannt. Hierbei wird vorgeschlagen ein Schlüs­ selpaar für das Steuergerät zum Ver- und Entschlüsseln von elektronischen Daten bereitzustellen. Die einzuspielende Soft­ ware wird mit dem ersten Schlüssel elektronisch signiert. Die elektronische Signatur wird durch das betreffende Steuergerät mittels des zweiten Schlüssels geprüft. Der zweite Schlüssel wurde bereits vor der Prüfung im Steuergerät abgelegt. Die Generierung der Schlüsselpaare kann im Fahrzeug oder außerhalb erfolgen. Wird das Schlüsselpaar für ein Steuergerät im Fahr­ zeug erzeugt, muss der erste Schlüssel auslesbar sein.
Die DE 100 08 973 A1 offenbart ein Verfahren, welches das in der DE 100 08 974 A1 offenbarte Verfahren auf mehrere Berech­ tigte mittels digitaler Signatur von Zertifikaten erweitert.
Der Artikel "Vehicular Implementation of Public Key Cryp­ tographic Techniques" (Arazi, B in IEEE Transaction on Vehicular Technology, Vol. 40, No. 3, August 1991, Seiten 646-653) offen­ bart wie Public-Key-Systeme in Fahrzeuge implementiert werden, wobei der Schwerpunkt auf die Kommunikation des Fahrzeugs bzw. des Fahrers mit externen Terminals gelegt ist, beispielsweise beim Zahlen von Maut- oder Parkgebühren oder beim Tanken.
Aus der EP 0 816 970 A2 ist ein Verfahren und eine Vorrichtung bekannt mittels derer beim Starten von Computer-Systemen eine Authentizitätsprüfung des Bootprogramms über ein Public- Private-Key-Verfahren erfolgt.
Die US 5844986 offenbart eine Vorrichtung zur Vermeidung von nicht-authorisierter Manipulation am BIOS von Computer- Systemen. Hierbei wird eine Aktualisierung des BIOS über ein Public-Key-Verfahren überprüft.
Im Fahrzeuginformations- und Fahrzeugsteuersystem eingesetzte Software- oder Hardware-Komponenten haben unterschiedliche Aufgaben, zu deren Bearbeitung Zugriffe auf beispielsweise Dateien, Treiber, Schnittstellen oder Datenbussysteme benötigt werden. Zugriffe dieser Art sind mit Datenaustausch zwischen den jeweiligen Komponenten verbunden und als sicherheitskri­ tisch anzusehen. Somit ist eine strikte Zugriffskontrolle er­ forderlich, so dass sich jede Komponente beim Zugriff auf eine andere Komponente authentisieren kann. Da die Komponenten von verschiedenen Herstellern stammen können, die unterschiedlich vertrauenswürdig sind, muss dafür Sorge getragen werden, dass eine falsche Identität nicht vorgetäuscht werden kann.
Die Informationen, die zwischen den Komponenten ausgetauscht werden, können vertraulichen Charakter haben, wenn beispiels­ weise Adressen, Passwörter, Geschäftspapiere, Terminkalender mittels des Fahrzeuginformations- und Fahrzeugsteuersystems verarbeitet werden. Das Fahrzeug kann von verschiedenen Fahrern benutzt werden, die im Allgemeinen unbeschränkten Zugang auf das komplette vernetzte System haben. Damit fällt es einem möglichen Angreifer sehr leicht Abhörgeräte in diesem vernetz­ ten System anzubringen. Zudem kann Datenverkehr auf einem Netz­ werk mittels Richtmikrofonen abgehört werden. Um die Vertrau­ lichkeit der im Fahrzeug mittels eines Datenbussystems übertra­ genen Information zu gewährleisten, muss diese Information verschlüsselt zwischen den einzelnen Komponenten übertragen werden.
Authentisierung und Verschlüsselung sind die zwei Sicherheits­ dienste, die hier von zentraler Bedeutung sind. Durch Ver­ schlüsselung kann Vertraulichkeit von übertragenen bzw. gespei­ cherten Daten erreicht werden. Bei Authentisierung werden zwei Arten von Authentisierung unterschieden: Authentisierung einer Entität und Authentisierung des Datenursprungs. Unter Authenti­ sierung einer Entität wird der Nachweis der Identität dieser Entität, hier Hardware- oder Software-Komponente, verstanden. Mit Hilfe der Authentisierung des Datenursprungs kann die Un­ verfälschtheit verschiedener Eigenschaften der übertragenen Daten garantiert werden, insbesondere Absender, Inhalt, Zeit­ punkt der Erstellung. Dieser Dienst impliziert insbesondere die Integrität der übertragenen Daten.
Das Public-Key-Verschlüsselungsverfahren ist unter anderem durch die Arbeiten von Diffie und Hellmann (W. Diffie, M. E. Hellmann, "New Directions in cryptography", IEEE Transactions on Information Theory, Vol. IT-22, November 1976, Seiten 644-­ 654) sowie von Rivest, Shamir und Adleman (R. Rivest, A. Shamir und L. Adleman, "A method for obtaining digital signatures and public-key cryptosystems", Communications of the ACM, Vol. 27, Nr. 2, Februar 1978, Seiten 120-126, das sogenannte RSA- Verfahren) bekannt. Bei diesem Verfahren werden zwei Schlüssel verwendet; einer zum Ver- und der andere zum Entschlüsseln. Dieses Verfahren wird auch als asymmetrisches Verschlüsselungs­ verfahren bezeichnet. Im Gegensatz dazu verwenden symmetrische Verschlüsselungsverfahren, wie beispielsweise DES, zum Veschlüsseln und Entschlüsseln denselben Schlüssel.
Die Trennung in einen öffentlichen und privaten Schlüssel bei asymmetrischer Verschlüsselung erleichtert das Schlüsselmanage­ ment erheblich, weil der zum Verschlüsseln benötigte öffentli­ che Schlüssel nicht geschützt werden muss und damit von allen Kommunikationspartnern verwendet werden kann. Aufgrund dieses Vorteils wird das Public-Key-Verfahren im Bereich der digitalen Signatur eingesetzt. Zertifizierungsstellen, sogenannte Trust- Center, übernehmen die Registrierung der Personen, die Schlüs­ selgenerierung und -vergabe sowie den Verzeichnisdienst für die öffentlichen Schlüssel. Zur digitalen Signatur signiert eine Person mit ihrem privaten Schlüssel das elektronische Dokument. Bei der Signatur wird der Hash-Wert, ein charakteristischer elektronischer Fingerabdruck, des elektronischen Dokuments ermittelt und verschlüsselt an das elektronische Dokument ange­ bunden. Der Empfänger kann mittels des öffentlichen Schlüssels die Authentizität des Absenders und durch Vergleich des aktuel­ len mit dem entschlüsselten Hash-Wertes die Integrität des erhaltenen Dokuments feststellen.
Das Konzept der Zertifizierungsstelle, auch Trust-Center ge­ nannt, hat den Vorteil, dass eine zentrale Stelle für die Au­ thentizität, der von ihr erstellten, ausgegebenen und verwalte­ ten Schlüsselpaare bürgt. Damit ist gewährleistet, dass sich die Teilnehmer auf die Authentizität der Schlüsselbesitzer verlassen können. Beispielsweise kann eine Person nur dann ein Schlüsselpaar zur Teilnahme an der digitalen Signatur erhalten, wenn diese sich vorher bei einer Zertifizierungsstelle über einen Ausweis authentifiziert hat. Damit wird beim Trust-Center der Kreis der zu vertrauenden Entitäten selektiert und es ent­ steht mit den zu vertrauenden Entitäten eine vertrauenswürdige Umgebung.
Der Anwendungsbereich des Public-Key-Verfahrens ist vielfältig. Welcher Schlüssel, also öffentlicher oder privater, zum Ver- bzw. Entschlüsseln verwendet wird, hängt von der Anwendung ab.
Das Public-Key-Verfahren kann auch zum Austausch von Schlüsseln für andere Verschlüsselungsverfahren wie Data Encryption Stan­ dard (DES) im Falle von symmetrischer Verschlüsselung verwendet werden. So kann der Vorteil der asymmetrischen Verfahren, also einfache Schlüsselverwaltung, mit dem Vorteil der symmetrischen Verfahren, also Geschwindigkeit, kombiniert werden.
Eine Übersicht über die verschiedenen Verschlüsselungsverfahren und deren Anwendung ist in dem Artikel "Der Kryptographie- Report", erschienen in der Zeitschrift Elektronik 22/2000, Seite 78-86, zu finden. Details können im Standardwerk "Hand­ book of Applied Cryptography" (A. Menezes, P. v. Oorschot, S. Vanstone, CRC Press, 1997) nachgeschlagen werden.
Authentisierung als auch Verschlüsselung können mittels des oben beschriebenen asymmetrischen Verschlüsselungsverfahrens realisiert werden, wenn die Entitäten im Besitz von Informatio­ nen sind, die den anderen Entitäten nicht bekannt sind, also ein Geheimnis haben. Dieses Geheimnis ist der private Schlüssel (PrivKey) der jeweiligen Entität. Die dazugehörigen öffentli­ chen Schlüssel (PubKey) müssen für alle Entitäten zur Verfügung stehen, wobei die Generierung des Schlüsselpaares sowie der Verzeichnisdienst idealerweise von zentraler Stelle erfolgt, um Authentizität der teilnehmenden Entitäten zu garantieren.
In der DE 196 52 256 A1 ist ein Verfahren zur Sicherung der Datenübertragung zwischen Steuereinheiten in einem Kraftfahr­ zeug offenbart, die über einen Datenbus miteinander kommunizie­ ren. Bei diesem Verfahren erfolgt die Kommunikation zwischen den Steuergeräten in verschlüsselter Form. Die Form der Ver­ schlüsselung hängt von einem in den Steuergeräten abgelegten geheimen Schlüssel und von einer zeitlich veränderlichen Zu­ fallsgröße ab. Das Verfahren ermöglicht eine sichere Kommunika­ tion auf dem Datenbus, da es sich um ein symmetrisches Ver­ schlüsselungsverfahren in Verbindung mit einem Zufallszahlgene­ rator handelt. Das Verfahren ist aufwendig, da vor dessen An­ wendung die Zufallszahlgenerierung stattfinden und diese Zu­ fallszahl allen teilnehmenden Steuergeräten mitgeteilt werden muss. Zudem steht zur Authentifizierung in der Kommunikation zwischen den Steuergeräten kein steuergerätbezogener Schlüssel bereit.
Es ist nun die Aufgabe der vorliegenden Erfindung, ein Verfah­ ren zur Absicherung der Kommunikation zwischen Rechnern und/oder Programmen in Verkehrsmitteln bereitzustellen, das ohne großen Aufwand durchführbar ist und ein sicheres Verfahren bei Datenbussystemen darstellt. Zudem soll das Verfahren derart gestaltet sein, dass nachgerüstete Komponenten in einfacher Weise in das Absicherungsverfahren eingebunden werden können.
Diese Aufgabe wird erfindungsgemäß durch die Merkmale des An­ spruchs 1 gelöst. Danach werden neue und/oder aktualisierte Programme nur über die Trust-Komponente in das Datenbussystem geladen. Die einzubringenden, neuen und/oder aktualisierten Programme sind digital signiert. Die Trust-Komponente prüft die Programme auf Sicherheit, um sicherzustellen, dass kein ge­ fälschtes Programm in das Datenbussystem gelangen kann. Die Prüfung der neuen und/oder aktualisierten geladenen Programme erfolgt mittels deren digitaler Signatur über ein externes Trust-Center, wobei bei erfolgreicher Prüfung auf Sicherheit die Trust-Komponente ein Schlüsselpaar bestehend aus einem öffentlichen und privaten Schlüssel für das Programm generiert und das Schlüsselpaar sowie der öffentliche Schlüssel der Trust-Komponente dem Programm angehängt wird.
Die Absicherung der Kommunikation zwischen den teilnehmenden Rechnern und/oder Programmen kann über Verschlüsselung mittels des Public-Key-Verfahrens Verfahrens durchgeführt werden. Da eine reine Public-Key-Verschlüsselung aufgrund der notwendigen hohen Rechenkapazitäten sehr langsam ist, wird im Allgemeines ein hybrides Verfahren eingesetzt. Danach wird das Public-Key- Verfahren zur Vereinbarung und Austausch eines gemeinsamen symmetrischen Schlüssels eingesetzt. Die eigentliche Verschlüs­ selung der Daten erfolgt dann mittels des symmetrischen Ver­ schlüsselungsverfahren, welches weniger Rechnerkapazität bindet und damit auch um ein Vielfaches schneller ist.
Das Public-Key-Verfahren kann auch zur Authentisierung der Rechner und/oder Programme sowie zur Daten-Authentisierung, insbesondere zur Prüfung der Datenintegrität, nach den oben beschriebenen Verfahren eingesetzt werden.
Die Trust-Komponente entspricht damit einem innerhalb des Ver­ kehrsmittels angeordneten internen Trust-Center und übernimmt die oben beschriebenen Aufgaben. Der Begriff Rechner soll jede Art von Steuergerät mit einschließen. Insbesondere Hardware- Komponenten, die mit entsprechender Software ausgestattet sind, die das Laden und Entladen von Programmen zur Laufzeit erlauben wie beispielsweise nach dem OSGi-Standard (Open Services Gate­ way Initiative, "OSGi Service Gateway Specification", Release 1.0, May 2000). Programme können Softwareprogramme, -module oder Daten sein.
Durch die vorteilhafte Einschränkung der Absicherung auf die fahrzeuginterne Kommunikation kann das Trust-Center in das Verkehrsmittel integriert werden und die Schlüsselgenerierung kann dynamisch innerhalb des Verkehrmittels erfolgen. Dadurch verliert die Anwendung des Public-Private-Key-Verfahrens für Datenbus-Netzwerke an Komplexität und eignet sich besonders für den Einsatz in Verkehrsmitteln, da keine Kommunikation mit einem außerhalb des Verkehrsmittels angeordneten Trust-Center notwendig ist.
Bei einer Weiterbildung des erfindungsgemäßen Verfahrens werden neue und/oder aktualisierte Programme nur über die Trust- Komponente in das Datenbussystem geladen. Die Trust-Komponente prüft die Programme auf Sicherheit, also deren Authentizität und Integrität, um sicherzustellen, dass kein gefälschtes Pro­ gramm in das Datenbussystem gelangen kann.
Mit Hilfe dieses Verfahrens wird eine vertrauenswürdige Umge­ bung innerhalb des Verkehrsmittels erhalten, da nur auf Sicher­ heit geprüfte Programme in das Datenbussystem geladen werden können.
Das erfindungsgemäße Verfahren lässt sich in vorteilhafter Weise weiterbilden, indem bei erfolgreicher Prüfung auf Sicher­ heit die Trust-Komponente ein Schlüsselpaar bestehend aus einem öffentlichen und privaten Schlüssel für das Programm generiert und das Schlüsselpaar sowie der öffentlichen Schlüssel der Trust-Komponente dem Programm angehängt wird.
Somit wird für ein auf Authentizität und Integrität geprüftes Programm während des Ladevorgangs das korrespondierende Schlüs­ selpaar dynamisch generiert. Das Programm ist ab diesem Zeit­ punkt ebenfalls Teil der vertrauenswürdigen Umgebung des Daten­ bussystems und kann an der sicheren Kommunikation teilnehmen.
Es gibt nun verschiedene Möglichkeiten, die Lehre der vorlie­ genden Erfindung in vorteilhafter Weise auszugestalten und weiterzubilden. Dazu ist einerseits auf die untergeordneten Ansprüche und andererseits auf die nachfolgende Erläuterung des Verfahrens zu verweisen. Es sollen auch die vorteilhaften Ver­ fahrensvarianten einbezogen sein, die sich aus einer beliebigen Kombination der Unteransprüche ergeben.
Das Fahrzeuginformations- und Fahrzeugsteuersystem besteht aus mehreren Rechnern, die miteinander über ein Datenbussystem verbunden sind. Innerhalb der Rechner laufen Softwareprogramme oder Softwaremodule ab. Sowohl die Rechner als auch die Soft­ wareprogramme kommunizieren über das Datenbussystem mit den anderen Rechnern und deren Softwareprogrammen und/oder Soft­ waremodulen. Die Rechner haben die Möglichkeit Softwareprogram­ me bzw. -module untereinander auszutauschen.
Nur einer der Rechner, im Folgenden als Trust-Komponente be­ zeichnet, besitzt eine Schnittstelle, die es erlaubt, zusätz­ liche Softwareprogramme von außen in das System einzubringen. Diese Trust-Komponente wird auch als Gateway-Lader oder Kommu­ nikationsplattform bezeichnet. Die Schnittstelle dieser Trust- Komponente weist ein drahtloses Datenübertragungsprotokoll wie GSM oder Bluetooth auf. Die Schnittstelle kann aber auch als serielle Schnittstelle ausgebildet sein, die über direkte An­ kopplung beispielsweise Daten von einer CD-ROM einlesen kann.
Die einzubringenden Softwareprogramme oder -module sind vom Hersteller digital signiert, so dass die Trust-Komponente mit dem oben beschriebenen Verfahren die Authentizität und Integri­ tät der gerade übertragenen Softwareprogramme oder -module und damit den Grad der Vertraulichkeit über ein externes Trust- Center prüfen kann. Damit die Trust-Komponente dazu in der Lage ist, muss vorher in einer sicheren Umgebung der öffentliche Schlüssel des externen Trust-Centers in der Trust-Komponente schreibgeschützt abgelegt werden.
In einer sicheren Umgebung, also bei der Herstellung des Ver­ kehrsmittels oder in einer Werkstatt, kann nun die Verteilung der Schlüssel, insbesondere der privaten Schlüssel, an die einzelnen Hardware-Komponenten, d. h. die Rechner und die Trust- Komponente, durchgeführt werden. Im ersten Schritt werden die Rechner in der sicheren Umgebung mit den privaten Schlüsseln ausgestattet und danach kann auch jedem Softwareprogramm bzw. - modul ein privater Schlüssel zugeordnet werden.
Dabei wird zuerst ein Schlüsselpaar, bestehend aus einem priva­ ten und einem öffentlichen Schlüssel (PrivKeyG, PubKeyG), für die Trust-Komponente durch die Trust-Komponente erzeugt und dort abgelegt. Bei der Installation der einzelnen Rechner wird wiederum von der Trust-Komponente für jeden Rechner ein Schlüs­ selpaar, bestehend aus (PrivKeyL, PubKeyL) generiert. Dieses Schlüsselpaar und der öffentliche Schlüssel (PubKeyG) der Trust-Komponente werden gemeinsam auf jedem Rechner abgelegt, der in die sichere Datenübertragung eingebunden sein soll. Der private Schlüssel des Rechners (PrivKeyL) wird gegen einen nicht autorisierten Lese- und Schreibzugriff geschützt. Für die öffentlichen Schlüssel (PubKeyG und PubKeyL) auf dem Rechner reicht lediglich ein Schreibschutz aus. Der öffentliche Schlüs­ sel (PubKeyL) des in eine Softwareprogrammübertragung eingebun­ denen Rechners, wird außerdem im Speicherbereich der Trust- Komponente schreibgeschützt abgelegt, da der öffentliche Schlüssel (PubKeyL) für das oben genannte Verschlüsselungsver­ fahren allen Rechnern zur Verfügung stehen muss.
Je nach verwendetem Verschlüsselungs- und Signierverfahren basiert die Generierung von Schlüsseln auf verschiedenen mathe­ matischen Theorien. Algorithmen zur Erzeugung von Schlüsseln für symmetrische und asymmetrische Verfahren können dem ein­ gangs zitierten Stand der Technik entnommen werden (siehe bei­ spielsweise Kapitel 4 und 5 in "Handbook of Applied Cryp­ tography", A. Menezes, P. v. Oorschot, S. Vanstone, CRC Press, 1997).
Bei diesem Verfahren ist von besonderer Wichtigkeit, dass die Rechner in einem ersten Schritt in einer sicheren Umgebung mit Schlüsseln ausgestattet werden. Die Schlüssel können, wie in dem Ausführungsbeispiel ausgeführt, von der systeminternen Trust-Komponente generiert werden, oder auch über ein externes Trust-Center zur Verfügung gestellt werden.
Nachdem alle Rechner mit den entsprechenden Schlüsseln im Sys­ tem versehen worden sind, enthält die Trust-Komponente einen privaten Schlüssel (PrivKeyG), der schreib- und lesegeschützt ist. Außerdem stellt die Trust-Komponente die öffentlichen Schlüssel für jeden einzelnen an der sicheren Datenübertragung beteiligten Rechner schreibgeschützt zur Verfügung.
Die Trust-Komponente dient damit im System als Zertifizierungs­ stelle und Vertrauenskomponente. Da alle anderen Rechner im Besitz des öffentlichen Schlüssels der Trust-Komponente sind, kann jederzeit ein einzelner Rechner den korrekten öffentlichen Schlüssel eines anderen Rechners von der Trust-Komponente er­ fragen. Des weiteren kann jederzeit eine gesicherte, also au­ thentisierte und vertrauliche Kommunikation nach dem oben be­ schriebenen Public-Key-Verfahren zwischen den Rechnern aufge­ baut werden.
Nachdem die Rechner und die Trust-Komponente in einer sicheren Umgebung installiert und mit den entsprechenden Schlüsseln ausgestattet sind, können im zweiten Schritt die Softwarepro­ gramme bzw. -module über das Trust-Center in das System geladen werden. Die neuen Softwareprogramme oder -module werden, wie oben beschrieben, auf ihre Authentizität und Integrität von der Trust-Komponente mittels eines externen Trust-Centers geprüft. Dadurch ist sichergestellt, dass keine gefälschten Softwarepro­ gramme, -module oder Daten auf die einzelnen Rechner weiter übertragen werden. Nach der Überprüfung eines neuen Software­ programms durch die Trust-Komponente erzeugt die Trust- Komponente ein neues Schlüsselpaar (PrivKeyN, PubKeyN) für dieses neue Softwareprogramm. Der öffentliche Schlüssel (Pub­ KeyN) wird in der Trust-Komponente schreibgeschützt abgelegt, so dass dieser allen Komponenten zur Anwendung des Verschlüsse­ lungs- und Authentisierungsverfahrens zur Verfügung stehen.
Anschließend werden an das übertragene Softwareprogramm sein Schlüsselpaar (PrivKeyN, PubKeyN) und der öffentliche Schlüs­ sels der Trust-Komponente (PubKeyG) angehängt. Mittels der oben beschriebenen Verschlüsselungsmechanismen zwischen Trust-Center und Rechner kann das Packet nun sicher zu dem betreffenden Rechner, der das Softwareprogramm von der Trust-Komponente oder einer externen Werkstatt angefordert hat, übertragen werden. Das Softwareprogramm legt den privaten Schlüssel schreib- und lesegeschützt ab, so dass der Schlüssel gegen nicht autorisier­ ten Zugriff geschützt ist. Der Rechner muss dafür Sorge tragen, dass die Softwareprogramme bzw. -module nicht die privaten Schlüssel weiterer auf ihm installierter Softwareprogramme bzw. -module lesen können.
Ab diesem Zeitpunkt ist ein neues Softwareprogramm mit einem eindeutig gesicherten Geheimnis in Form eines privaten Schlüs­ sels (PrivKeyN) ausgestattet. Da der entsprechende öffentliche Schlüssel (PubKeyN) für jedes Softwareprogramm in der Trust- Komponente abgelegt ist, kann jederzeit von jedem Softwarepro­ gramm der öffentliche Schlüssel eines anderen Softwareprogramms gesichert abgefragt werden. Wenn ein Softwareprogramm von einem anderen Rechner übertragen wird, nimmt das Softwareprogramm die Schlüssel bei der Übertragung mit, in dem die Schlüssel hinten an die übertragenen Daten angehängt werden. Da zwischen den Rechnern eine gesicherte Verbindung aufgebaut wird, kann der private Schlüssel während der Datenübertragung über den Daten­ bus nicht abgehört werden.

Claims (5)

1. Verfahren zur Absicherung der Kommunikation zwischen Rechnern und Programmen in einem Verkehrsmittel,
wobei die Rechner und Programme Daten mittels eines Datenbus­ ses austauschen,
der Datenaustausch verschlüsselt und/oder authentisiert stattfindet,
kryptographische Schlüssel in den Rechnern und/oder Program­ men abgelegt werden, wobei
zur Absicherung der Kommunikation ein Public-Key-Verfahren herangezogen wird, wobei an dem Public-Key-Verfahren teilneh­ menden Rechnern und/oder Programmen jeweils ein entsprechendes Schlüsselpaar bestehend aus einem öffentlichen sowie einem privaten Schlüssel von einer Trust-Komponente zugewiesen wird, wobei
die Trust-Komponente von einem der Rechner innerhalb des Verkehrsmittels gebildet wird,
dadurch gekennzeichnet, dass
neue und/oder aktualisierte Programme nur über die Trust- Komponente in das Datenbussystem geladen werden,
die einzubringenden, neuen und/oder aktualisierten Programme digital signiert sind,
die Trust-Komponente die Programme auf Sicherheit prüft, um sicherzustellen, dass kein gefälschtes Programm in das Daten­ bussystem gelangen kann,
die Prüfung der neuen und/oder aktualisierten geladener. Pro­ gramme mittels deren digitaler Signatur über ein externes Trust-Center erfolgt, wobei
bei erfolgreicher Prüfung auf Sicherheit die Trust-Komponente ein Schlüsselpaar bestehend aus einem öffentlichen und privaten Schlüssel für das Programm generiert und
das Schlüsselpaar sowie der öffentliche Schlüssel der Trust- Komponente dem Programm angehängt wird.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass bei der Prüfung auf Sicherheit eine Prüfung auf Authenti­ zität und/oder Integrität des Programms erfolgt.
3. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass beim Verschieben eines Programms auf einen anderen Rechner das Schlüsselpaar bestehend aus einem privaten und einem öf­ fentlichen Schlüssel des Programms nicht neu vergeben wird.
4. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass
beim Verschieben eines Programms auf einen anderen Rechner ein Datenpaket bestehend aus dem Programm, dem Schlüsselpaar des Programms sowie dem öffentlichen Schlüssel der Trust- Komponente gebildet wird und
dieses Datenpaket zwischen den Rechnern verschlüsselt über­ tragen wird, um die vertrauenswürdige Umgebung in dem Datenbus- System zu gewährleisten.
5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet,
dass zur Absicherung der Kommunikation
Verschlüsselung mittels des Public-Key-Verfahrens durchge­ führt wird und/oder
Authentisierung der Rechner und/oder Programme mittels des Public-Key-Verfahrens Verfahrens durchgeführt wird und/oder
Daten-Authentisierung mittels des Public-Key-Verfahrens durchgeführt wird.
DE2001141737 2001-08-25 2001-08-25 Verfahren zur sicheren Datenübertragung innerhalb eines Verkehrsmittels Expired - Fee Related DE10141737C1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE2001141737 DE10141737C1 (de) 2001-08-25 2001-08-25 Verfahren zur sicheren Datenübertragung innerhalb eines Verkehrsmittels

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE2001141737 DE10141737C1 (de) 2001-08-25 2001-08-25 Verfahren zur sicheren Datenübertragung innerhalb eines Verkehrsmittels

Publications (1)

Publication Number Publication Date
DE10141737C1 true DE10141737C1 (de) 2003-04-03

Family

ID=7696625

Family Applications (1)

Application Number Title Priority Date Filing Date
DE2001141737 Expired - Fee Related DE10141737C1 (de) 2001-08-25 2001-08-25 Verfahren zur sicheren Datenübertragung innerhalb eines Verkehrsmittels

Country Status (1)

Country Link
DE (1) DE10141737C1 (de)

Cited By (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004004203A1 (en) * 2002-06-28 2004-01-08 Motorola, Inc., A Corporation Of The State Of Delaware Method and system for component authentication in a vehicle
EP1127756A3 (de) * 2000-02-25 2004-04-21 Bayerische Motoren Werke Aktiengesellschaft Autorisierungsverfahren mit Zertifikat
DE10309507A1 (de) * 2003-03-05 2004-09-16 Volkswagen Ag Verfahren und Einrichtung zur Wartung von sicherheitsrelevanten Programmcode eines Kraftfahrzeuges
EP1482394A2 (de) * 2003-05-28 2004-12-01 Robert Bosch Gmbh Verfahren zur Steuerung des Zugriffs auf eine Ressource einer Applikation in einer Datenverarbeitungseinrichtung
WO2004114131A1 (de) * 2003-06-24 2004-12-29 Bayerische Motoren Werke Aktiengesellschaft Verfahren zum nachladen einer software in den bootsektor eines programmierbaren lesespeicher
WO2005003936A1 (de) * 2003-07-04 2005-01-13 Bayerische Motoren Werke Aktiengesellschaft Verfahren zur authentifikation von insbesondere in ein steuergerät eines kraftfahrzeugs ladbaren softwarekomponenten
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
DE10332452A1 (de) * 2003-07-17 2005-02-03 Continental Aktiengesellschaft Steuerungs- und Regelungsgerät in einem Kraftfahrzeug sowie Verfahren zum Betreiben desselben
DE10348209A1 (de) * 2003-10-16 2005-05-12 Volkswagen Ag Verfahren und System zur Analyse von Einrichtungen eines Verkehrsmittels und/oder eines Zustands eines Verkehrsmittels
WO2005116834A1 (de) * 2004-04-29 2005-12-08 Bayerische Motoren Werke Aktiengesellschaft Authentisierung von steuerge­räten in einem fahrzeug
US7181615B2 (en) 2002-06-28 2007-02-20 Motorola, Inc. Method and system for vehicle authentication of a remote access device
EP1760623A2 (de) * 2005-08-18 2007-03-07 Siemens Aktiengesellschaft Sicherheitseinrichtung für elektronische Geräte
US7228420B2 (en) 2002-06-28 2007-06-05 Temic Automotive Of North America, Inc. Method and system for technician authentication of a vehicle
DE102006018831A1 (de) * 2006-04-22 2007-10-25 Daimlerchrysler Ag Kraftfahrzeugdiagnose und Fahrzeugannahme
US7325135B2 (en) 2002-06-28 2008-01-29 Temic Automotive Of North America, Inc. Method and system for authorizing reconfiguration of a vehicle
EP1959606A1 (de) * 2007-02-13 2008-08-20 Secunet Security Networks Aktiengesellschaft Sicherheitseinheit
DE102007052993A1 (de) * 2007-11-05 2009-05-07 Volkswagen Ag Kommunikationsknoten und Verfahren zur Kommunikation zwischen mindestens zwei Kommunikationsknoten in einem Car2X-Kommunikationsnetzwerk
DE102007058975A1 (de) * 2007-12-07 2009-06-10 Bayerische Motoren Werke Aktiengesellschaft Bordnetz eines Kraftfahrzeugs mit einem Master Security Modul
US7549046B2 (en) 2002-06-28 2009-06-16 Temic Automotive Of North America, Inc. Method and system for vehicle authorization of a service technician
US7600114B2 (en) 2002-06-28 2009-10-06 Temic Automotive Of North America, Inc. Method and system for vehicle authentication of another vehicle
DE102008018001A1 (de) * 2008-04-09 2009-10-22 Siemens Aktiengesellschaft Verfahren und Vorrichtung zur Übertragung von Nachrichten in Echtzeit
WO2013131900A1 (de) * 2012-03-06 2013-09-12 Continental Teves Ag & Co. Ohg Verfahren zur verbesserung der funktionalen sicherheit und steigerung der verfügbarkeit eines elektronischen regelungssystems sowie ein elektronisches regelungssystem
US8886943B2 (en) 2004-04-29 2014-11-11 Bayerische Motoren Werke Aktiengesellschaft Authentication of a vehicle-external device
DE102004023128B4 (de) 2004-05-03 2018-07-12 Volkswagen Ag Vorrichtung und Verfahren zur Kontrolle von Diensten in einem Fahrzeug
DE102019000976A1 (de) * 2019-02-11 2020-08-13 Giesecke+Devrient Mobile Security Gmbh Sicherheitsmodus bei ersetzten ECUs

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0816970A2 (de) * 1996-07-01 1998-01-07 Sun Microsystems, Inc. Verfahren und Vorrichtung zur Authentifizierung von Firmwaren
DE19652256A1 (de) * 1996-12-16 1998-06-18 Bosch Gmbh Robert Verfahren zur Sicherung der Datenübertragung
US5844986A (en) * 1996-09-30 1998-12-01 Intel Corporation Secure BIOS
DE10008973A1 (de) * 2000-02-25 2001-09-06 Bayerische Motoren Werke Ag Autorisierungsverfahren mit Zertifikat
DE10008974A1 (de) * 2000-02-25 2001-09-06 Bayerische Motoren Werke Ag Signaturverfahren

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
DE19652256A1 (de) * 1996-12-16 1998-06-18 Bosch Gmbh Robert Verfahren zur Sicherung der Datenübertragung
DE10008973A1 (de) * 2000-02-25 2001-09-06 Bayerische Motoren Werke Ag Autorisierungsverfahren mit Zertifikat
DE10008974A1 (de) * 2000-02-25 2001-09-06 Bayerische Motoren Werke Ag Signaturverfahren

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ARAZI, B.: Vehicular Implementation of Public Key Cryptographic Techniques. In: IEEE Trans- actions on Vehicular Technology, Vol. 40, No. 3, August 1991, S. 646-653 *

Cited By (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1127756A3 (de) * 2000-02-25 2004-04-21 Bayerische Motoren Werke Aktiengesellschaft Autorisierungsverfahren mit Zertifikat
US7197637B2 (en) 2000-02-25 2007-03-27 Bayerische Motoren Werke Aktiengesellschaft Authorization process using a certificate
WO2004004203A1 (en) * 2002-06-28 2004-01-08 Motorola, Inc., A Corporation Of The State Of Delaware Method and system for component authentication in a 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
US7325135B2 (en) 2002-06-28 2008-01-29 Temic Automotive Of North America, Inc. Method and system for authorizing reconfiguration of a vehicle
US7600114B2 (en) 2002-06-28 2009-10-06 Temic Automotive Of North America, Inc. Method and system for vehicle authentication of another vehicle
US7228420B2 (en) 2002-06-28 2007-06-05 Temic Automotive Of North America, Inc. Method and system for technician authentication of a vehicle
US7181615B2 (en) 2002-06-28 2007-02-20 Motorola, Inc. Method and system for vehicle authentication of a remote access device
DE10309507A1 (de) * 2003-03-05 2004-09-16 Volkswagen Ag Verfahren und Einrichtung zur Wartung von sicherheitsrelevanten Programmcode eines Kraftfahrzeuges
EP1482394A3 (de) * 2003-05-28 2005-11-02 Robert Bosch Gmbh Verfahren zur Steuerung des Zugriffs auf eine Ressource einer Applikation in einer Datenverarbeitungseinrichtung
US7502794B2 (en) 2003-05-28 2009-03-10 Robert Bosch Gmbh Method for controlling access to a resource of an application in a data-processing device
EP1482394A2 (de) * 2003-05-28 2004-12-01 Robert Bosch Gmbh Verfahren zur Steuerung des Zugriffs auf eine Ressource einer Applikation in einer Datenverarbeitungseinrichtung
DE10357032A1 (de) * 2003-06-24 2005-01-13 Bayerische Motoren Werke Ag Verfahren zum Nachladen einer Software in den Bootsektor eines programmierbaren Lesespeicher
WO2004114131A1 (de) * 2003-06-24 2004-12-29 Bayerische Motoren Werke Aktiengesellschaft Verfahren zum nachladen einer software in den bootsektor eines programmierbaren lesespeicher
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
US7748043B2 (en) 2003-07-04 2010-06-29 Bayerische Motoren Werke Aktiengesellschaft Method for authenticating, in particular, software components that can be loaded into a control unit of a motor vehicle
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
WO2005003936A1 (de) * 2003-07-04 2005-01-13 Bayerische Motoren Werke Aktiengesellschaft Verfahren zur authentifikation von insbesondere in ein steuergerät eines kraftfahrzeugs ladbaren softwarekomponenten
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
DE10332452A1 (de) * 2003-07-17 2005-02-03 Continental Aktiengesellschaft Steuerungs- und Regelungsgerät in einem Kraftfahrzeug sowie Verfahren zum Betreiben desselben
DE10348209A1 (de) * 2003-10-16 2005-05-12 Volkswagen Ag Verfahren und System zur Analyse von Einrichtungen eines Verkehrsmittels und/oder eines Zustands eines Verkehrsmittels
WO2005116834A1 (de) * 2004-04-29 2005-12-08 Bayerische Motoren Werke Aktiengesellschaft Authentisierung von steuerge­räten in einem fahrzeug
US8886943B2 (en) 2004-04-29 2014-11-11 Bayerische Motoren Werke Aktiengesellschaft Authentication of a vehicle-external device
DE102004023128B4 (de) 2004-05-03 2018-07-12 Volkswagen Ag Vorrichtung und Verfahren zur Kontrolle von Diensten in einem Fahrzeug
EP1760623A2 (de) * 2005-08-18 2007-03-07 Siemens Aktiengesellschaft Sicherheitseinrichtung für elektronische Geräte
EP1760623A3 (de) * 2005-08-18 2009-03-04 Continental Automotive GmbH Sicherheitseinrichtung für elektronische Geräte
DE102006018831A1 (de) * 2006-04-22 2007-10-25 Daimlerchrysler Ag Kraftfahrzeugdiagnose und Fahrzeugannahme
EP1959606A1 (de) * 2007-02-13 2008-08-20 Secunet Security Networks Aktiengesellschaft Sicherheitseinheit
DE102007052993A1 (de) * 2007-11-05 2009-05-07 Volkswagen Ag Kommunikationsknoten und Verfahren zur Kommunikation zwischen mindestens zwei Kommunikationsknoten in einem Car2X-Kommunikationsnetzwerk
US8380978B2 (en) 2007-12-07 2013-02-19 Bayerische Motoren Werke Aktiengesellschaft Electrical system of a motor vehicle with a master security module
DE102007058975B4 (de) 2007-12-07 2022-10-06 Bayerische Motoren Werke Aktiengesellschaft Bordnetz eines Kraftfahrzeugs mit einem Master Security Modul
DE102007058975A1 (de) * 2007-12-07 2009-06-10 Bayerische Motoren Werke Aktiengesellschaft Bordnetz eines Kraftfahrzeugs mit einem Master Security Modul
US8577036B2 (en) 2008-04-09 2013-11-05 Siemens Aktiengesellschaft Method and device for transmitting messages in real time
DE102008018001A1 (de) * 2008-04-09 2009-10-22 Siemens Aktiengesellschaft Verfahren und Vorrichtung zur Übertragung von Nachrichten in Echtzeit
WO2013131900A1 (de) * 2012-03-06 2013-09-12 Continental Teves Ag & Co. Ohg Verfahren zur verbesserung der funktionalen sicherheit und steigerung der verfügbarkeit eines elektronischen regelungssystems sowie ein elektronisches regelungssystem
US9576137B2 (en) 2012-03-06 2017-02-21 Continental Teves Ag & Co. Ohg Method and system for analyzing integrity of encrypted data in electronic control system for motor vehicle
EP2823430B1 (de) 2012-03-06 2018-11-07 Continental Teves AG & Co. OHG Elektronisches regelungssystem
JP2015511905A (ja) * 2012-03-06 2015-04-23 コンチネンタル・テベス・アーゲー・ウント・コンパニー・オーハーゲー 機能安全を改善し、電子閉ループ制御システムの可用性を増す方法、および電子閉ループ制御システム
DE102019000976A1 (de) * 2019-02-11 2020-08-13 Giesecke+Devrient Mobile Security Gmbh Sicherheitsmodus bei ersetzten ECUs

Similar Documents

Publication Publication Date Title
DE10141737C1 (de) Verfahren zur sicheren Datenübertragung innerhalb eines Verkehrsmittels
EP1128242B1 (de) Signaturverfahren
EP2962439B1 (de) Lesen eines attributs aus einem id-token
DE60119857T2 (de) Verfahren und Vorrichtung zur Ausführung von gesicherten Transaktionen
DE102010028133A1 (de) Verfahren zum Lesen eines Attributs aus einem ID-Token
EP2567501B1 (de) Verfahren zum kryptographischen schutz einer applikation
DE102009027723A1 (de) Verfahren zum Lesen von Attributen aus einem ID-Token
EP2238733A2 (de) Vorrichtung und verfahren zur sicheren datenübertragung in einem tachographensystem
EP2332284A2 (de) Freischalten eines dienstes auf einem elektronischen gerät
DE102020121533A1 (de) Vertrauenswürdige authentifizierung von automotiven mikrocon-trollern
DE102020205993B3 (de) Konzept zum Austausch von kryptographischen Schlüsselinformationen
EP3114600A1 (de) Sicherheitssystem mit Zugriffskontrolle
EP1287655B1 (de) Verfahren zur authentizitätssicherung von hard- und software in einem vernetzten system
EP1801724B1 (de) Verfahren und Anordnung zum Bereitstellen sicherheitsrelevanter Dienste durch ein Sicherheitsmodul einer Frankiermaschine
DE102020117552A1 (de) Sichere hybrid-boot-systeme und sichere boot-verfahren für hybridsysteme
EP3321832A1 (de) Verteilen zum lesen von attributen aus einem id-token
WO2014037070A1 (de) Verfahren zur erstellung einer abgeleiteten instanz eines originaldatenträgers
EP3244331B1 (de) Verfahren zum lesen von attributen aus einem id-token
EP3901714B1 (de) Verfahren zur überprüfung der authentizität von elektronischen modulen eines modular aufgebauten feldgeräts der automatisierungstechnik
EP1988484A2 (de) Gegen Kopieren geschützte Chipkarte und Verfahren im Zusammenhang mit deren Herstellung
DE112022004542T5 (de) Sichere kommunikation in einem rechensystem
DE102021001919A1 (de) Verfahren zum sicheren Verteilen eines Softwareupdates
EP3244332B1 (de) Verfahren zum lesen von attributen aus einem id-token
WO2024046681A1 (de) Verfahren zur authentifizierung von daten
EP1054364A2 (de) Verfahren zur Erhöhung der Sicherheit bei digitalen Unterschriften

Legal Events

Date Code Title Description
8100 Publication of the examined application without publication of unexamined application
8304 Grant after examination procedure
8364 No opposition during term of opposition
8327 Change in the person/name/address of the patent owner

Owner name: DAIMLERCHRYSLER AG, 70327 STUTTGART, DE

8327 Change in the person/name/address of the patent owner

Owner name: DAIMLER AG, 70327 STUTTGART, DE

R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee

Effective date: 20140301