EP4781315A1 - Verfahren zur absicherung der kommunikation in einem fahrzeug - Google Patents

Verfahren zur absicherung der kommunikation in einem fahrzeug

Info

Publication number
EP4781315A1
EP4781315A1 EP25801560.1A EP25801560A EP4781315A1 EP 4781315 A1 EP4781315 A1 EP 4781315A1 EP 25801560 A EP25801560 A EP 25801560A EP 4781315 A1 EP4781315 A1 EP 4781315A1
Authority
EP
European Patent Office
Prior art keywords
security module
hardware security
processes
key
data
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.)
Pending
Application number
EP25801560.1A
Other languages
English (en)
French (fr)
Inventor
Thorsten Wilmer
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
Mercedes Benz Group 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 Mercedes Benz Group AG filed Critical Mercedes Benz Group AG
Publication of EP4781315A1 publication Critical patent/EP4781315A1/de
Pending 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/606—Protecting data by securing the transmission between two devices or processes
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H04L9/0897—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage involving additional devices, e.g. trusted platform module [TPM], smartcard or USB
    • 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/3234—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 additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • 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
    • 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)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • General Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • Bioethics (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • Storage Device Security (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zur Absicherung der Kommunikation zwischen auf vernetzten Steuergeräten in einem Fahrzeug laufenden Prozessen (4, 5), wozu in einem Hardware-Sicherheits-Modul (1) hinterlegtes kryptografisches Material (2) genutzt wird. Erfindungsgemäß ist es dabei vorgesehen, dass wenigstens einer der Prozesse (4, 5) einen Sitzungsschlüssel (3. 3') direkt mit dem Hardware-Sicherheits-Modul (1) aushandelt, wonach das Hardware-Sicherheits-Modul (1) dem Prozess (4, 5) einen von dem Prozess (4, 5) angefragten oder einen seitens des Hardware-Sicherheits-Modul (1) dem Prozess (4, 5) zugeordneten Schlüssel verfügbar macht, wobei das Hardware- Sicherheits-Modul (1) sicherstellt, dass der dadurch einem bestimmten Prozess (4, 5) zugeordnete Schlüssel nicht nochmal für einen anderen Prozess (4, 5) verwendet wird, indem das Hardware-Sicherheits-Modul (1) Buch darüber führt, welche Schlüssel einem der Prozesse (4,5) zugeordnet worden sind und die die weitere Nutzung eines solchen bereits vergebenen Schlüssel durch einen neuen Prozess (4, 5) verbietet, wobei über einen abgesicherten Modus beim Hochfahren der vernetzten Steuergeräte sichergestellt wird, dass zuerst nur sichere Prozesses (4, 5) geladen werden, die einen Sitzungsschlüssel (3, 3') direkt mit dem Hardware-Sicherheits-Modul (1) aushanden können.

Description

Mercedes-Benz Group AG
Verfahren zur Absicherung der Kommunikation in einem Fahrzeug
Die Erfindung betrifft ein Verfahren zur Absicherung der Kommunikation zwischen auf vernetzten Steuergeräten in einem Fahrzeug laufenden Prozessen, wozu in einem Hardware-Sicherheits-Modul hinterlegtes kryptografisches Material genutzt wird.
Ganz allgemein kann bezüglich der abgesicherten Kommunikation zwischen laufenden Prozessen auf die US 2024 / 0 111 907 A1 verwiesen werden. Diese zeigt ein Hardware- Sicherheits-Modul in welchem verschiedenen Clients zugeordnete Schlüssel abgelegt sind.
Zum weiteren Stand der Technik kann ferner die US 2003 / 0 069 939 A1 genannte werden. Dort wird eine Kommunikation zwischen zwei Netzwerkkonten beschrieben, die einen gemeinsamen Speicher nutzen. Der Speicher umfasst dabei für jedes Paar der Netzwerkkonten zwei Speicherbereiche, in die jeweils einer der Netzwerkkonten nur schreiben und den der jeweils andere der Netzwerkkonten nur lesen kann.
AUTOSAR (AUTomotive Open System ARchitecture) ist eine 2003 gegründete weltweite Entwicklungspartnerschaft von Automobilherstellern, Zulieferern und anderen Unternehmen aus der Elektronik-, Halbleiter- und Softwareindustrie. Sie verfolgt den Zweck, eine offene und standardisierte Softwarearchitektur für elektronische Steuergeräte (ECUs) zu entwickeln und zu etablieren. Ein entscheidender Aspekt sind dabei auch die Sicherheitsanforderungen. Neue Anwendungsfälle, wie z.B. das hochautomatisierte Fahren, erforderten die Entwicklung einer adaptive Plattform. Diese bildet beispielsweise auch die Kommunikation mit anderen Fahrzeugen (Car2Car) aber auch mit Systemen außerhalb der Fahrzeuge, wie z.B. der Verkehrsinfrastruktur (Car2X), zuverlässig ab. Die AUTOSAR Adaptive Plattform dient dazu die dynamische Bereitstellung von Kundenanwendungen zu unterstützen und Rahmenbedingungen für die Anwendungen bereitzustellen, die High-End-Rechenleistung erfordern. Der Kern ihrer Standardisierung ist ein Betriebssystem, das auf dem POSIX-Standard basiert, z.B. QNX. Die adaptive Plattform von AUTOSAR enthält sowohl Spezifikation als auch Code. Diese Implementierung steht allen AUTOSAR-Partnern zur Verfügung.
Ein entscheidender Aspekt ist dabei, wie oben schon angedeutet, die zunehmenden Anforderung an die Sicherheit der Kommunikation, insbesondere zwischen den vernetzten elektronischen Steuergeräten innerhalb eines Fahrzeugs. Ein gängigen Ansatz im Stand der Technik ist dabei die Verwendung von kryptografischen Material, welches in einem sogenannten Hardware-Sicherheits-Modul (HSM) hinterlegt ist. Ein solches Hardware-Sicherheits-Modul oder Hardware Security Modul ist dabei ein besonders manipulationssicheres Gerät, welches die kryptografische Prozesse schützt, indem es Schlüssel, die zur Ver- und Entschlüsselung von Daten sowie zum Erstellen digitaler Signaturen und Zertifikate genutzt werden, generiert, schützt und verwaltet.
Als Schnittstelle zwischen den auf den Steuergeräten ablaufenden Prozessen und dem Hardware-Sicherheits-Modul dient dabei ein Device-Treiber. Das Problem ist nun, dass es zu sehr vielen Kommunikationskontakten zu dem Hardware-Sicherheits-Modul über den Device-Treiber kommt. Dies führt in der Praxis zu einer sehr hohen Menge an Kernel- Aufrufen. Nach ersten Schätzung kann die Menge bei mehreren zehntausend Kernel- Aufrufen pro Sekunde liegen, was eine enorme Systembelastung darstellt und schlimmstenfalls gar nicht zu handhaben ist.
Die Aufgabe der hier vorliegenden Erfindung ist es daher eine verbessertes Verfahren zur Absicherung der Kommunikation gemäß dem Oberbegriff des Anspruchs 1 anzugeben, welche -insbesondere in der adaptiven AUTOSAR Umgebung- eine sichere Kommunikation ohne oder mit zumindest sehr stark reduzierter Anzahl an Kernel-Aufrufen ermöglicht.
Erfindungsgemäß wird diese Aufgabe durch ein Verfahren mit den Merkmalen im Anspruch 1 , und hier insbesondere im kennzeichnenden Teil des Anspruchs 1, gelöst. Vorteilhafte Ausgestaltungen des erfindungsgemäßen Verfahrens ergeben sich aus den hiervon abhängigen Unteransprüchen. Das Verfahren dient zur Absicherung der Kommunikation zwischen auf vernetzten Steuergeräten (ECUs) in einem Fahrzeug laufenden Prozessen, also letztlich zur kryptografischen Absicherung (Verschlüsselung, Authentifizierung und/oder Signatur) der übertragenen Daten. Ähnlich wie im Stand der Technik wird dazu in einem Hardware- Sicherheits-Modul (HSM) hinterlegtes kryptografisches Material genutzt.
Erfindungsgemäß ist es nun aber vorgesehen, dass wenigstens einer der Prozesse, idealerweise aber alle der Prozesse, einen (eigenen) Sitzungsschlüssel direkt mit dem Hardware-Sicherheits-Modul aushandelt. Der (jeweilige) Prozess kommuniziert also direkt mit dem HSM, wodurch der bisher übliche Device-Treiber eingespart werden kann. Damit fallen beim erfindungsgemäßen Verfahren keine Kernel-Aufrufe mehr an. Bevor der (jeweilige) Prozess mit dem Hardware-Sicherheits-Modul kommuniziert baut er sich durch den Sitzungsschlüssel (Session Key) ein „vertrautes“ Verhältnis auf. Erst nachdem dies erfolgreich war, macht das Hardware-Sicherheits-Modul dem (jeweiligen) Prozess einen von dem Prozess angefragten oder einen seitens des Hardware-Sicherheits-Modul dem Prozess zugeordneten noch freien Schlüssel verfügbar. Verfügbarmachen im Sinne der Erfindung bedeutet dabei, dass der (jeweilige) Prozess über den Schlüssel verfügen kann, um Daten abgesichert mit anderen Prozessen auf anderen Steuergeräten auszutauschen. Nun könnte der dem (jeweiligen) Prozess zugeordnete Schlüssel im Prinzip über den Sitzungsschlüssel abgesichert von dem Hardware-Sicherheits-Modul an den Prozess übertragen werden. Dies wird jedoch typischerweise nicht gemacht, da der Schlüssel das Hardware-Sicherheits-Modul aus Sicherheitsgründen nie verlassen sollte. Im Allgemeinen ist daher unter dem Verfügbarmachen zu verstehen, dass der (jeweilige) Prozess z.B. die Daten mit dem Sitzungsschlüssel abgesichert an das Hardware-Sicherheits-Modul übermittelt, welches diese mit dem dem (jeweiligen) Prozess zugeordneten Schlüssel signiert und über den Sitzungsschlüssel abgesichert an den Prozess zurückgibt, welcher die signierten Daten dann versendet.
Ein für die Sicherheit relevanter Aspekt des erfindungsgemäßen Verfahrens ist es nun, dass das Hardware-Sicherheits-Modul sicherstellt, dass der einem bestimmten Prozess zugeordnete Schlüssel nicht nochmal für einen anderen Prozess verwendet wird. Es vergibt also nur Schlüssel, die noch frei sind. Damit kann ausgeschlossen werden, das eine schädlicher Prozess sich des Schlüssels eines anderen bereits laufenden Prozesses bedient. Dazu führt das Hardware-Sicherheits-Modul gemäß der Erfindung Buch darüber, welche Schlüssel einem der Prozesse zugeordnet worden sind, und verbietet die weitere Nutzung eines solchen bereits vergebenen Schlüssel durch einen neuen Prozess. Dadurch kann das Hardware-Sicherheits-Modul sicherstellen, dass jeder Prozess nur dann einen Schlüssel benutzen kann, wenn nicht schon vorher ein anderer Prozess denselben Schlüssel benutzt hat. Ein Mitlesen und sich Aneignen eines Schlüssels durch einen dritten bösartigen Prozess wird somit zur Laufzeit der Prozesses sicher ausgeschlossen.
Dabei wird über einen abgesicherten Modus beim Hochfahren der vernetzten Steuergeräte sichergestellt, dass zuerst nur sichere Prozesses geladen werden, die einen Sitzungsschlüssel direkt mit dem Hardware-Sicherheits-Modul aushanden können. Dadurch und durch die Zuordnung der Schlüssel zu bestimmten Prozessen, kann verhindert werden, dass eine bösartiger Prozess nachgeladen wird, welcher dann einen von ihm mitgelesenen bzw. gekidnappten Schlüssel zur abgesicherten Kommunikation nutzen könnte.
Besonders günstig ist es dabei, wenn gemäß einer vorteilhaften Ausgestaltung jeder laufende Prozess einen Sitzungsschlüssel direkt mit dem Hardware-Sicherheits-Modul aushandelt, wonach der Prozess die an einen anderen Prozess in einem anderen Steuergerät sicher zu übermittelnden Daten oder eine für die sicher zu übermittelnden Daten charakteristische Größe mit dem Sitzungsschlüssel geschützt an das Hardware- Sicherheits-Modul übermittelt. Der Prozess nutzt also den Sitzungsschlüssel, um die Daten bzw. die charakteristische Größe zu schützen, vorzugsweise indem es diese mit dem Sitzungsschlüssel signiert. Alternativ oder ergänzend wäre auch eine Verschlüsselung mit dem Sitzungsschlüssel denkbar, dies erfordert jedoch zusätzlichen Rechenaufwand und Ressourcen. Im Anschluss signiert nun das Hardware-Sicherheits- Modul die sicher zu übermittelnden Daten oder die für die sicher zu übermittelnden Daten charakteristische Größe mit dem dem Prozess zugeordneten Schlüssel des HSMs. Hier kommt nun also der im Hardware-Sicherheits-Modul bzw. seinem sicheren Speicher hinterlegte mit dem jeweiligen Prozess eindeutig verknüpfte Schlüssel zum Einsatz. Diese Signatur wird dann mit dem Sitzungsschlüssel gesichert an den Prozess zurück übermittelt. Auch hier kann bevorzugt eine Signatur mit dem Sitzungsschlüssel zum Einsatz kommen, eine Verschlüsselung mit dem Sitzungsschlüssel wäre jedoch auch hier denkbar. Der Prozess kann die so empfangene Signatur mit dem dem Prozess zugeordneten Schlüssel des Hardware-Sicherheitsmoduls zusammen mit den sicher zu übermittelnden Daten dann an den anderen Prozess in dem anderen Steuergerät abgesichert übermitteln.
Gemäß einer besonders günstigen Weiterbildung hiervon kann es dabei vorgesehen sein, dass die Übermittlung zwischen dem jeweiligen Prozess und dem Hardware-Sicherheits- Modul über einen gemeinsam genutzten Speicher erfolgt. Sowohl das Hardware- Sicherheits-Modul als auch der Prozess nutzt dabei den Sitzungsschlüssel um die Inhalte, die in den gemeinsam genutzten Speicher geschrieben werden abzusichern. Dies stellt eine einfache und sehr effizient Art der Übermittlung dar. Sie ist auch sehr sicher, insbesondere wenn gewährleistet werden kann, dass nur entweder das Hardware- Sicherheits-Modul oder der Prozess bzw. ein Betriebssystem, in welchem der Prozess abläuft, in den gemeinsam genutzten Speicher schreiben kann. Vorzugsweise ist es deshalb vorgesehen, dass der gemeinsam genutzte Speicher zwei Speicherbereiche umfasst, wobei in den ersten Speicherbereich nur durch das Hardware-Sicherheits-Modul geschrieben werden kann, wobei in den zweiten Speicherbereich nur durch die Prozesse geschrieben werden kann, und wobei beide Speicherbereiche für das Hardware- Sicherheits-Modul und die Prozesses lesbar sind.
Anstelle der Daten selbst kann, wie oben bereits erwähnt, auch eine charakteristische Größe der sicher zu übermittelnden Daten genutzt werden, um so die Daten mittelbar zu signieren und den Datenverkehr in der Kommunikation mit dem Hardware-Sicherheits- Modul zu begrenzen. Bei dieser charakteristischen Größe kann es sich gemäß einer sehr vorteilhaften Ausgestaltung um den inhaltlichen Kern der Daten, die sogenannte Payload, und/oder einen Hashwert von zumindest einem Teil der Daten handeln.
Das Aushandeln des Sitzungsschlüssel zwischen dem Prozess und der Hardware- Sicherheits-Modul kann gemäß einer günstigen Weiterbildung des erfindungsgemäßen Verfahrens mittels eines Diffie-Hellman-Schlüsseltauschs erfolgen. Eine solcher Diffie- Hellman-Schlüsselaustausch ist ein bekanntes und etabliertes Verfahren, mit dem sich ein gemeinsamer Sitzungsschlüssel zwischen zwei Kommunikationspartnern sicher über ein potenziell unsicheres Übertragungsmedium vereinbaren lässt. Das Verfahren kommt für zahlreiche kryptographische Protokolle im Internet zum Einsatz und ist bewährt.
Eine vorteilhafte Weiterbildung sieht es ferner vor, dass die Prozesses innerhalb eines Steuergeräts sequenziell gestartet werden. In einem Steuergerät werden die verschiedenen Prozesse also der Reihe nach gestartet. Damit ist es besonders einfach für das Hardware-Sicherheits-Modul der Reihe nach mit den einzelnen Prozessen Sitzungsschlüssel auszuhandeln.
Wie Eingangs dargelegt soll das erfindungsgemäße Verfahren bevorzugt im Bereich des adaptive AUTOSAR zum Einsatz kommen. Dazu soll die Signatur durch das Hardware- Sicherheits-Modul nach dem Secure On-Board Communication Protocol (SecOC) erfolgen. Secure On-Board Communication ist als Informationssicherheitskomponente in die AUTOSAR-Architektur integriert. Es umfasst verschiedene Funktionen, darunter Ver- und Entschlüsselungsvorgänge, Schlüsselverwaltung sowie Verwaltung und Verteilung neuer Werte.
Die Daten liegen dabei bevorzugt in Form von einer Protokolldateneinheit (Protocol Data Unit (PDU)) vor. Unter einer Protokolldateneinheit ist dabei die grundlegende Austauscheinheit zwischen Entitäten, die über ein bestimmtes Netzwerkprotokoll kommunizieren, zu verstehen. Im hier vorliegenden Fall handelt es sich also um Signale, die zwischen Steuergeräten z.B. über einen CAN-Bus übermittelt bzw. ausgetauscht werden. Gemäß AUTOSAR können die Protokolldateneinheiten neben den eigentlichen Daten auch noch Layer-Informationen beinhalten.
Weitere vorteilhafte Ausgestaltungen des erfindungsgemäßen Verfahrens ergeben sich auch anhand des Ausführungsbeispiels, welches nachfolgend unter Bezugnahme auf die Figur näher beschrieben ist.
Die einzige beigefügte Figur 1 zeugt dabei ein Schema zur Erläuterung des erfindungsgemäßen Verfahrens.
In der Darstellung der Figur 1 ist dabei rechts das Hardware-Sicherheits-Modul 1 zu erkennen. Es umfasst die darunter dargestellte Box 2 mit dem kryptografischen Material bzw. den Schlüsseln des Hardware-Sicherheits-Modul 1 für die abgesicherte On-Board- Kommunikation zwischen Steuergeräten.
In einem Steuergerät mit Adaptive AUTOSAR, werden dabei die verschiedenen Prozesse, von denen in Figur 1 zwei bespielhaft dargestellt und mit 4, 5 bezeichnet sind, der Reihe nach gestartet. Typischerweise hat ein Prozess ein Set von Protokolldateneinheiten bzw. PDUs. Der jeweilige Prozess 4, 5 und das Hardware-Sicherheits-Modul 1 führen nun einen Schlüsseltausch, bevorzugt nach Diffie Helman, aus. Damit liegt nun beiden ein Sitzungsschlüssel vor, den sich das Hardware-Sicherheits-Modul 1 und der Prozess „ausgedacht“ haben. In Figur 1 ist dieser Sitzungsschlüssel neben dem jeweiligen Prozess 4, 5 durch die mit 3, 3‘ bezeichnete Box angedeutet. Neben dem Hardware- Sicherheits-Modul 1 ist die den Sitzungsschlüssel darstellende Box mit 3 und 3‘ bezeichnet, da das Hardware-Sicherheits-Modul 1 die Sitzungsschlüssel mit allen Prozessen 4, 5 benötigt. Idealerweise werden diese Sitzungsschlüssel nach dem Start des jeweiligen Prozesses 4, 5 ausgetauscht und bleiben dieselben bis der Prozess 4, 5 beendet wird. Sobald die Sitzungsschlüssel 3, 3‘ ausgehandelt sind, wird die Kommunikation zwischen Prozess 4, 5 und dem Hardware-Sicherheits-Modul 1 mit diesem Sitzungsschlüssel 3, 3‘ signiert.
Sollen nun Daten bzw. eine PDU von einem Steuergerät in dem Fahrzeug zu einem anderen versendet werden, dann übermittelt z.B. der Prozess 4 die PDU, deren Payload oder einen diese PDU charakterisierenden Hash-Wert mit dem Sitzungsschlüssel 3 signiert an das Hardware-Sicherheits-Modul 1. Das Hardware-Sicherheits-Modul 1 signiert danach die PDU, deren Payload oder den Hash-Wert des Prozesses 4 nach dem bekannte SecOC Protokoll mit einem Schlüssel aus dem Schlüsselmaterial 2 des Hardware-Sicherheits-Modul 1 , welchen dieses dem Prozess 4 zugeordnet hat. Im Anschluss übermittelt das Hardware-Sicherheits-Modul 1 die so erzeugte Signatur mit dem Sitzungsschlüssel 3 signiert an den Prozess 4 zurück. Dieser kann dann die PDU zusammen mit der vom Hardware-Sicherheits-Modul 1 erzeugten Signatur sicher versenden.
Das Hardware-Sicherheits-Modul 1 führt Buch darüber, welche Schlüssel einem der Prozesse 4, 5 zugeordnet worden sind und verbietet die weitere Nutzung eines solchen bereits vergebenen Schlüssel durch einen neuen Prozess 4, 5. Dadurch kann das Hardware-Sicherheits-Modul 1 sicherstellen, dass jeder Prozess 4, 5 nur dann einen Schlüssel benutzen kann, wenn nicht schon vorher ein anderer Prozess 5, 4 denselben Schlüssel benutzt hat. Ein Mitlesen und sich Aneignen eines Schlüssels durch einen dritten bösartigen Prozess wird somit zur Laufzeit der Prozesses 4, 5 sicher ausgeschlossen. Durch ein abgesichertes Hochfahren (Secure Boot) des gesamten Systems, z.B. beim Start des Fahrzeugs, wird sichergestellt, dass zunächst nur vertrauenswürdige Prozesse 4, 5 starten. Das Nachladen eines bösartigen Prozesses, welcher dann unerlaubt einen Schlüssel zur SecOC Kommunikation benutzt, wird damit verhindert.
Um das Übermitteln der durch den Sitzungsschlüssel 3, 3‘ signierten Daten zu erleichtern können das Hardware-Sicherheits-Modul 1 und das Betriebssystem, z.B. QNX, in dem die Prozesses 4, 5 laufen, gemeinsam auf einen geteilten Speicher 6 zugreifen. Dieser ist so aufgebaut, dass nur entweder das Hardware-Sicherheits-Modul 1 oder das Betriebssystem bzw. die in ihm laufenden Prozesse 4, 5 schreiben können. Sowohl das Hardware-Sicherheits-Modul 1 als auch das Betriebssystem bzw. die in ihm laufenden Prozesse 4, 5 können jedoch alles lesen. Dies kann beispielsweise so realisiert werden, dass der gemeinsame Speicher 6 zwei Speicherbereiche umfasst, wobei in den ersten Speicherbereich nur das Hardware-Sicherheits-Modul 1 schreiben kann und in den zweiten Speicherbereich nur die Prozesse 4, 5. Beide Speicherbereiche sind aber für das Hardware-Sicherheits-Modul 1 und die Prozesses 4, 5 lesbar. Damit können die vom Prozess 4, 5 oder vom Hardware-Sicherheits-Modul 1 mit den jeweiligen Sitzungsschlüssel 3, 3‘ signierten Inhalte in den gemeinsamen Speicher e geschrieben und von dem jeweils anderen Kommunikationspartner ausgelesen werden.

Claims

Mercedes-Benz Group AG Patentansprüche
1. Verfahren zur Absicherung der Kommunikation zwischen auf vernetzten Steuergeräten in einem Fahrzeug laufenden Prozessen (4, 5), wozu in einem Hardware-Sicherheits-Modul (1) hinterlegtes kryptografisches Material (2) genutzt wird, dadurch gekennzeichnet, dass wenigstens einer der Prozesse (4, 5) einen Sitzungsschlüssel (3. 3‘) direkt mit dem Hardware-Sicherheits-Modul (1) aushandelt, wonach das Hardware-Sicherheits- Modul (1) dem Prozess (4, 5) einen von dem Prozess (4, 5) angefragten oder einen seitens des Hardware-Sicherheits-Modul (1) dem Prozess (4, 5) zugeordneten Schlüssel verfügbar macht, wobei das Hardware-Sicherheits-Modul (1) sicherstellt, dass der dadurch einem bestimmten Prozess (4, 5) zugeordnete Schlüssel nicht nochmal für einen anderen Prozess (4, 5) verwendet wird, indem das Hardware- Sicherheits-Modul (1) Buch darüber führt, welche Schlüssel einem der Prozesse (4,5) zugeordnet worden sind und die die weitere Nutzung eines solchen bereits vergebenen Schlüssel durch einen neuen Prozess (4, 5) verbietet, wobei über einen abgesicherten Modus beim Hochfahren der vernetzten Steuergeräte sichergestellt wird, dass zuerst nur sichere Prozesses (4, 5) geladen werden, die einen Sitzungsschlüssel (3, 3‘) direkt mit dem Hardware-Sicherheits-Modul (1) aushanden können.
2. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass jeder der Prozesse (4, 5) einen Sitzungsschlüssel (3, 3‘) direkt mit dem Hardware- Sicherheits-Modul (1) aushandelt, wonach der Prozess (4, 5) die an einen anderen Prozess (4, 5) in einem anderen Steuergerät sicher zu übermittelnden Daten oder eine für die sicher zu übermittelnden Daten charakteristische Größe mit dem Sitzungsschlüssel (3, 3‘) geschützt en das Hardware-Sicherheits-Modul (1) übermittelt, wonach das Hardware-Sicherheits-Modul (1) die sicher zu übermittelnden Daten oder die für die sicher zu übermittelnden Daten charakteristische Größe mit dem dem Prozess (4, 5) zugeordneten Schlüssel des Hardware-Sicherheits-Moduls (1) signiert und dem Prozess (4, 5) diese Signatur mit dem Sitzungsschlüssel (3, 3‘) gesichert übermittelt, und wonach der Prozess (4, 5) diese Signatur zusammen mit den sicher zu übermittelnden Daten an den anderen Prozess (4, 5) in dem anderen Steuergerät übermittelt.
3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass die Übermittlung zwischen dem jeweiligen Prozess (4, 5) und dem Hardware- Sicherheits-Modul (1) über einen gemeinsam genutzten Speicher (6) erfolgt.
4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass der gemeinsam genutzte Speicher (6) zwei Speicherbereiche umfasst, wobei in den ersten Speicherbereich nur durch das Hardware-Sicherheits-Modul (1) geschrieben werden kann, wobei in den zweiten Speicherbereich nur durch die Prozesse (4, 5) geschrieben werden kann, und wobei beide Speicherbereiche für das Hardware- Sicherheits-Modul (1) und die Prozesse (4, 5) lesbar sind.
5. Verfahren nach einem der Ansprüche 2 bis 4, dadurch gekennzeichnet, dass das die charakteristische Größe der sicher zu übermittelnden Daten den inhaltlichen Kern der Daten und/oder einen Hashwert von zumindest einem Teil der Daten umfasst.
6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass das Aushandeln des Sitzungsschlüssel (3, 3‘) mittels eines Diffie-Hellman- Schlüsseltauschs erfolgt.
7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass die Prozesse (4, 5) innerhalb eines Steuergeräts sequenziell gestartet werden.
8. Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass die Signatur durch das Hardware-Sicherheits-Modul (1) nach dem Secure On-Board Communication Protocol erfolgt.
9. Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass die Daten in Form von Protokolldateneinheiten vorliegen.
EP25801560.1A 2024-12-12 2025-11-08 Verfahren zur absicherung der kommunikation in einem fahrzeug Pending EP4781315A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102024004167.2A DE102024004167B3 (de) 2024-12-12 2024-12-12 Verfahren zur Absicherung der Kommunikation in einem Fahrzeug
PCT/EP2025/082375 WO2026124869A1 (de) 2024-12-12 2025-11-08 Verfahren zur absicherung der kommunikation in einem fahrzeug

Publications (1)

Publication Number Publication Date
EP4781315A1 true EP4781315A1 (de) 2026-07-29

Family

ID=97677887

Family Applications (1)

Application Number Title Priority Date Filing Date
EP25801560.1A Pending EP4781315A1 (de) 2024-12-12 2025-11-08 Verfahren zur absicherung der kommunikation in einem fahrzeug

Country Status (3)

Country Link
EP (1) EP4781315A1 (de)
DE (1) DE102024004167B3 (de)
WO (1) WO2026124869A1 (de)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6920485B2 (en) 2001-10-04 2005-07-19 Hewlett-Packard Development Company, L.P. Packet processing in shared memory multi-computer systems
WO2022153055A1 (en) 2021-01-15 2022-07-21 Ncipher Security Limited A device and a communication method

Also Published As

Publication number Publication date
WO2026124869A1 (de) 2026-06-18
DE102024004167B3 (de) 2026-02-26

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20260409

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR