DE102018202996A1 - Verfahren zum Durchführen einer Diagnose - Google Patents

Verfahren zum Durchführen einer Diagnose Download PDF

Info

Publication number
DE102018202996A1
DE102018202996A1 DE102018202996.2A DE102018202996A DE102018202996A1 DE 102018202996 A1 DE102018202996 A1 DE 102018202996A1 DE 102018202996 A DE102018202996 A DE 102018202996A DE 102018202996 A1 DE102018202996 A1 DE 102018202996A1
Authority
DE
Germany
Prior art keywords
switch
tester
diagnostic
microcontroller
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.)
Pending
Application number
DE102018202996.2A
Other languages
English (en)
Inventor
Siddharth Shukla
Mikael Sahlstroem
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.)
Robert Bosch GmbH
Original Assignee
Robert Bosch GmbH
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 Robert Bosch GmbH filed Critical Robert Bosch GmbH
Priority to DE102018202996.2A priority Critical patent/DE102018202996A1/de
Priority to CN201910145088.9A priority patent/CN110213221B/zh
Publication of DE102018202996A1 publication Critical patent/DE102018202996A1/de
Pending legal-status Critical Current

Links

Images

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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/029—Firewall traversal, e.g. tunnelling or, creating pinholes
    • 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0236—Filtering by address, protocol, port number or service, e.g. IP-address or URL
    • 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/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • 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/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • 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/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/141—Setup of application sessions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H04L67/5651—Reducing the amount or size of exchanged application data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/62—Establishing a time schedule for servicing the requests

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Small-Scale Networks (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum Durchführen einer Diagnose in einem Fahrzeug, bei dem mit einem externen Tester (340) über einen Diagnoseanschluss (342) auf eine Komponente des Fahrzeugs zugegriffen wird, wobei der Zugriff über ein Gateway (300), das einen Diagnoseanschluss (342) und einen Schalter (302) aufweist, erfolgt, wobei der Schalter (302) einen Schalter-Kern (308) und eine Schalter-CPU (304) umfasst, wobei im Rahmen der Diagnose Daten zu und von einem Mikrocontroller (320) eines Leitrechners übertragen werden, wobei bei dem Verfahren zunächst eine Verbindung zwischen dem Tester (340) und dem Diagnoseanschluss (342) aufgebaut wird, wobei hierbei eine verringerte Datenrate durch den Schalter (302) eingestellt wird, bis ein sicherer Datentunnel aufgebaut ist.

Description

  • Die Erfindung betrifft ein Verfahren zum Durchführen einer Diagnose in einem Fahrzeug und eine Anordnung zum Durchführen des Verfahrens. Die Erfindung betrifft weiterhin ein Computerprogramm und ein maschinenlesbares Speichermedium zum Durchführen des Verfahrens.
  • Stand der Technik
  • Diagnoseverfahren im Kraftfahrzeug werden eingesetzt, um die Funktionsweise von Komponenten des Fahrzeugs und damit die Funktionsfähigkeit des gesamten Fahrzeugs zu überwachen. Unter einer Diagnose versteht man dabei das Erkennen eines Fehlers und die Ermittlung der Fehlerursache aufgrund erfasster Daten. Dabei ist es in vielen Fällen erforderlich, von außen bzw. extern auf Komponenten bzw. Geräte des Kraftfahrzeugs zuzugreifen. Der Zugriff kann dabei über das Internet erfolgen. In diesem Zusammenhang ist das DolP (Diagnostics over Internet Protocol) bekannt. Damit wird ein Kommunikationsprotokoll der Automobilelektronik bezeichnet.
  • Ein typisches Ethernet-Schalter basiertes Gateway, das einen Netzübergang bezeichnet, im Fahrzeug muss sämtliche Ethernet-Pakete aus verschiedenen Fahrzeugbereichen zu dem Mikrocontroller des Leit- bzw. Hostrechners senden, um Entscheidungen, die die Firewall und das Leiten bzw. Routen der Daten betreffen, treffen zu können. Dies macht es erforderlich, dass die Firewall als Ganzes auf dem Mikrocontroller des Leitrechners implementiert wird und dass Daten von dem Fahrzeug und von einem einzelnen Ethernet-Anschluss zu dem Mikrocontroller des Leitrechners transportiert werden. Dies bringt sowohl für den Mikrocontroller des Leitrechners als auch für den Ethernet-Anschluss, der den Mikrocontroller des Leitrechners und den Schalter verbindet, einen erheblichen Mehraufwand bzw. Overhead mit sich und stellt daher eine nicht skalierbare Lösung dar.
  • Aus Sicherheitsgründen ist es jedoch von Vorteil, dass der externe unsichere Diagnoseanschluss direkt mit dem Mikrocontroller des Leitrechners verbunden ist, so dass die Pakete von dem unsicheren Anschluss direkt über eine Firewall zu dem Mikrocontroller des Leitrechners gesendet werden können. Der Nachteil ist hierbei, dass es einen zusätzlichen Overhead verursacht, den Mikrocontroller des Leitrechners mit einer Firewall abzusichern. Es ist ebenfalls zu berücksichtigen, dass, wenn der Anschluss angegriffen bzw. kompromittiert wird, der vollständige Zugang kompromittiert werden kann, da das Gateway der Zugangspunkt für alle Steuergeräte in dem Fahrzeugnetzwerk ist.
  • Ein modernes und intelligentes Ethernet-Schalter basiertes Gateway im Fahrzeug kann eine Ethernet-Firewall innerhalb des Schalters selbst aufweisen, da der Schalter über eine eigene CPU verfügt. Der größte Vorteil besteht darin, dass dieser den gesamten Verkehr innerhalb des Fahrzeugs nicht zu dem Mikrocontroller des Leitrechners senden muss. Der Schalter selbst ist ein sogenanntes SoC (System-on-a-Chip) mit Mikrocontroller, wobei die CPU des Schalters mit dem Schalter verbunden ist und eine 2-GBit-Schnittstelle verwendet wird. Daher müssen die Daten nicht zu dem Mikrocontroller des Leitrechners gesendet werden, der nicht einmal eine Zieladresse für den Mikrocontroller des Leitrechners hat. Somit wird eine größere Kommunikationsbandbreite des Gesamtsystems bereitgestellt.
  • Ein Diagnoseanschluss in dem Fahrzeug, wie bspw. OBD (Onboard Diagnose) oder DoIP, stellt einen Zugang zu der Zentraleinheit in dem Fahrzeug bereit. Daher kann, wenn der Diagnoseanschluss des Fahrzeugs kompromittiert wird, ein Angreifer vollen Zugriff auf das Fahrzeug erlangen. Der Diagnoseanschluss stellt mehrere kritische Dienste, wie ein Aktualisieren der Firmware und einen Zugriff auf vertrauliche kritische Daten bereit.
  • Die Druckschrift DE 10 2015 214 423 A1 beschreibt ein Verfahren zum Sichern von Betriebsparametern eines Kraftfahrzeugs, bei dem ein Hypervisor eine Anwendung und einen Fahrtenschreiber gemeinsam auf einer Hardware eines visualisierten Steuergeräts betreibt. Dabei bezieht der Fahrtenschreiber die Betriebsparameter von der Anwendung und zeichnet diese auf der Hardware auf. Ein Diagnosewerkzeug ist mit einem weiteren Steuergerät verbunden. Dieses Diagnosewerkzeug liest die Betriebsparameter aus der Hardware aus.
  • Offenbarung der Erfindung
  • Vor diesem Hintergrund werden ein Verfahren mit den Merkmalen des Anspruchs 1 und eine Anordnung zum Durchführen des Verfahrens gemäß Anspruch 8 vorgestellt. Es werden weiterhin ein Computerprogramm nach Anspruch 9 sowie ein maschinenlesbares Speichermedium gemäß Anspruch 10 vorgestellt.
  • Es wird somit ein insbesondere rechnergestütztes Verfahren zur Durchführung einer Diagnose einer Komponente, bspw. eines Steuergeräts, eines Fahrzeugs vorgestellt, bei dem ausgehend von einer externen Recheneinheit auf das Gerät zugegriffen werden kann. Dabei soll die Komponente vor unzulässigen Zugriffen geschützt werden. Zudem ist der Einsatz einer Firewall vorgesehen. Weiterhin ist vorgesehen, dass die Bandbereite eines Diagnoseanschlusses für einen bestimmten Zeitraum insbesondere stark reduziert wird.
  • Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und den beigefügten Zeichnungen.
  • Es versteht sich, dass die voranstehend genannten und die nachstehend noch zu erläuternden Merkmale nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar sind, ohne den Rahmen der vorliegenden Erfindung zu verlassen.
  • Figurenliste
    • 1 zeigt ein schalterbasiertes Gateway nach dem Stand der Technik.
    • 2 zeigt die Funktionsweise des Gateway aus 1.
    • 3 zeigt den DoIP-Prozess.
    • 4 zeigt den vorgeschlagenen sicheren Diagnosevorgang.
  • Ausführungsformen der Erfindung
  • Die Erfindung ist anhand von Ausführungsformen in den Zeichnungen schematisch dargestellt und wird nachfolgend unter Bezugnahme auf die Zeichnungen ausführlich beschrieben.
  • 1 zeigt ein Schalter basiertes Standard-Gateway, das insgesamt mit der Bezugsziffer 10 bezeichnet ist. Die Darstellung zeigt einen Standard-Ethernet-Schalter 11 mit einem Schalter-Kern 12 als Standard-Ethernet-Schalter mit Verbindungen 14 zu verschiedenen Fahrzeugdomänen, die auf verschiedenen VLANs zugewiesen sind. Die Darstellung zeigt weiterhin einen Mikrocontroller 20 eines Leitrechners mit einer Anwendungssoftware 22, einer AUTOSAR-Laufzeitumgebung 24, Kommunikationsdienste 26, einem PDU-Router 28, einer Ethernet-Schnittstelle 30, einer LIN-Schnittstelle 32 und einer CAN-Schnittstelle 34. Weiterhin zeigt die Darstellung einen Tester 40, eine Verbindung 42 für den Datenverkehr von allen VLANs sowie eine Diagnoseanschluss 44.
  • Bei dem gezeigten Aufbau ist der Tester 40 direkt mit dem DoIP-Flanken- bzw. Kantenknoten verbunden, d. h. mit dem Mikrocontroller 20 des Leitrechners. Ein Kantenknoten (edge node) ist der Endpunkt in einem Fahrzeug, bspw. ein Steuergerät oder ein Gateway, der für eine DolP-Kommunikation eingerichtet ist. Der Mikrocontroller 20 des Leitrechners ist somit ein Kantenknoten und daher wird ein TLS-Tunnel zwischen dem Tester 40 und dem Mikrocontroller 20 des Leitrechners als Gateway eingerichtet.
  • Ebenfalls ist der zweite Ethernet-Anschluss in dem Mikrocontroller 20 des Leitrechners mit dem Ethernet-Schalter in Form eines Verwaltungsanschlusses verbunden. Der gesamte Datenverkehr, der in jeden Anschluss des Schalters gelangt, muss zu dem Mikrocontroller 20 des Leitrechners geleitet werden, für jede der IP-Adressen basierend auf Routing-Entscheidungen. Daher ist eine vollständige Implementierung des Routing und der Firewall in dem Mikrocontroller 20 des Leitrechners vorzunehmen. Ein solches Design ist auf eine Weise ineffizient, dass ein Überfluten des gesamten Pakets zu dem Mikrocontroller 20 des Leitrechners den Datenverkehr reduzieren kann, den ein Ethernet-Schalter basiertes Gateway abfertigen kann. Mit weiteren Sensoren und Steuergeräten in zukünftigen Fahrzeugsystemen ist jedoch eine hohe Bandbreite erforderlich. Daher ist dieses Design hinsichtlich der Bandbreite nicht übermäßig skalierbar. Auch hinsichtlich der Sicherheit gibt es nur ein Level an Sicherheit. Daher kann, wenn der Diagnoseanschluss durch einen Angreifer kompromittiert wird, dieser Angreifer Zugang zu dem Fahrzeug erlangen.
  • 2 zeigt ein intelligentes Ethernet-Schalter basiertes automotives Gateway, das insgesamt mit der Bezugsziffer 100 bezeichnet ist. Die Darstellung zeigt einen intelligenten Ethernet-Schalter 102 mit CPU 104, Schnittstelle UNIMAC 106 und Schalter-Kern 108 und Verbindungen 110 zu verschiedenen Fahrzeugdomänen, die auf unterschiedlichen VLANs zugewiesen sind. UNIMAC 106 ist somit eine Schnittstelle, die den Schalter-Kern-Netzwerkanschlüsse direkt mit dem RAM (Random Access Memory) der Schalter-CPU 104 verbindet. Die Darstellung zeigt weiterhin einen Mikrocontroller 120 eines Leitrechners mit einer Anwendungssoftware 122, einer AUTOSAR-Laufzeitumgebung 124, Kommunikationsdienste 126, einem PDU-Router 128, einer Ethernet-Schnittstelle 130, einer LIN-Schnittstelle 132 und einer CAN-Schnittstelle 134. Weiterhin sind ein Tester 140 und ein Diagnoseanschluss 142 gezeigt.
  • Bei dem Design bzw. Aufbau besteht die Firewall für das Gateway-Signal auf der CPU 104, die sich innerhalb des Schalters 102 befindet. Von besonderem Vorteil dabei ist, dass die Signale von verschiedenen Fahrzeugdomänen auf mehreren VLANs (Virtual Local Area Network) nicht zu dem Mikrocontroller 120 des Leitrechners geleitet werden müssen, um Entscheidungen hinsichtlich des Routing zu treffen. Das Routing und der Einsatz der Firewall wird durch die Schalter-CPU 104 durchgeführt. Der Schalterkern 108 wird mit der internen CPU 104 verbunden, wobei eine 2-GBit-Ethernet-Schnittstelle verwendet wird, die die hohe Bandbreite (Pfeile 150) unterstützt. Einer der Schalteranschlüsse wird als Diagnoseanschluss 142 verwendet und die Diagnosesignale gelangen durch die Firewall und werden dann zu dem Mikrocontroller 120 des Leitrechners geleitet.
  • Obwohl dies eine in hohem Maße skalierbare Lösung darstellt, besteht ein Hauptanliegen darin, die Diagnose-Kommunikationssignale von anderen fahrzeuginternen Signalen zu trennen und ebenfalls die Kommunikation auf mehreren Leveln zu sichern.
  • Nachfolgend wird das vorgeschlagene Verfahren in seiner Gesamtheit beschrieben, das eine sichere Diagnosekommunikation in einem intelligenten Ethernet-Schalter basierten Gateway ermöglicht. Zunächst wird erklärt, wie eine DoIP-Kommunikation erfolgt, dann wird detailliert beschrieben, wie diese gesichert werden kann.
  • 3 zeigt eine Beschreibung eines Standard-DoIP-Kommunikationsprozesses. Bezug wird genommen auf ISO 13400-2. Die Darstellung zeigt in einem Szenariodiagramm insbesondere den DoIP-Kommunikationsinitiierungsablauf. Die Darstellung zeigt einen Tester 200 und einen DolP-Kantenknoten 202
  • Der Tester 200 bzw. der externe Nutzer ist mit dem Diagnoseanschluss verbunden, wobei einer der verfügbaren Ethernet-Schalter-Anschlüsse verwendet wird.
  • Die DolP-Kommunikation findet in folgenden Schritten statt:
    1. 1. Schritt: Tester 200 initiiert eine Verbindung mit einem DolP-Kantenknoten 202:
      1. a) Der Tester 200 sendet zunächst eine Fahrzeugidentifikationsanfrage an einen DolP-Kantenknoten 202, d. h. eine Leit-CPU (Pfeil 210).
      2. b) Der DolP-Kantenknoten 202 antwortet darauf mit einer Fahrzeugidentifikationsantwort an den Tester 200 (Pfeil 212).
      3. c) Der Tester 200 sendet nun eine Anfrage an den DolP-Kantenknoten 202, um ein Routen zu aktivieren (Pfeil 214).
      4. d) Der DolP-Kantenknoten 202 antwortet darauf mit einer Tester-Routing-Aktivierungsantwort (Pfeil 216).
    2. 2. Schritt: Ein TLS-Tunnel (TLS: Transport Layer Security) wird zwischen dem DolP-Kantenknoten 202 und dem Tester 200 für eine sichere und integritätsgeschützte Kommunikation erzeugt (Pfeil 220):
      1. a) Nachdem der Tunnel erzeugt wurde, fragt der Tester 200 bei dem DoIP-Kantenknoten 202 an, um ein Routen zu ermöglichen, um weiter mit dem Steuergerät in dem Fahrzeug verbunden zu sein (Pfeil 222).
      2. b) Der DolP-Kantenknoten 202 antwortet mit einer Routing-Aktivierungsantwort (Pfeil 224).
    3. 3. Schritt: Nun ist das Routen und die Datenübertragung zu/von anderen Steuergeräten in dem Fahrzeug erlaubt (Pfeil 230):
      1. a) Der Tester 200 sendet eine UDS-Serviceanfrage (UDS: Unified Diagnostic Service) (Pfeil 232).
      2. b) Der Tester 200 bekommt die Antwort zurück (Pfeil 234).
      3. c) Diese UDS-Dienste sind kritisch, da sie einen Zugang auf vertrauliche Daten ermöglichen und ein Überschreiben der Firmware gestatten.
  • Nachdem der TLS-Tunnel zwischen dem Tester 200 und dem Leitrechner des Mikrocontrollers als Gateway eingerichtet wurde, kann der Tester 200 ein Zugang anfordern, um selbst mit internen Steuergeräten 250 innerhalb des Fahrzeugs zu kommunizieren, die mit dem Gateway über CAN, Ethernet, LIN bzw. Flex Ray verbunden sind. Dann wäre die Verbindung wie Tester zu/von Gateway und Gateway zu/von internes Steuergerät 250, was bedeutet, dass ein Prozess mit zwei (Pfeile 236, 238) oder mehr Schritten durchgeführt werden würde, um Zugang auf das bzw. die internen Steuergeräte 250 zu erlangen.
  • Die Architektur für eine sichere Diagnose in einem intelligenten schalterbasierten Gateway ist in 4 gezeigt. Die Darstellung zeigt einen vorgeschlagenen sicheren Diagnoseprozess anhand eines Schalter basierten Gateways, das insgesamt mit der Bezugsziffer 300 bezeichnet ist. Die Darstellung zeigt einen intelligenten Etnernet-Schalter 302 mit CPU 304, die auf ein RAM zugreift, UNIMAC 306 und Schalter-Kern 308 und Verbindungen 310 zu verschiedenen Fahrzeugdomänen, die auf unterschiedlichen VLANs zugewiesen sind. Die Darstellung zeigt weiterhin ein Mikrocontroller 320 eines Leitrechners mit einer Anwendungssoftware 322, einer AUTOSAR-Laufzeitumgebung 324, Kommunikationsdienste 326, einem PDU-Router 328, einer Ethernet-Schnittstelle 330, einer LIN-Schnittstelle 332 und einer CAN-Schnittstelle 334. Weiterhin sind ein Tester 340 und ein Diagnoseanschluss 342 gezeigt. Die Schritte, um diesen Prozess zu vervollständigen, werden nachfolgend definiert.
  • 4 erklärt, dass, wenn das Diagnosepaket von dem Diagnoseschalteranschluss zu dem Mikrocontroller 320 des Leitrechners geleitet wird, es eine vollständig andere Route als andere Pakete hat. Der Schalterkern 308 wird mit der Schalter-CPU 304 verbunden, wobei mehrere Datenreihen verwendet werden. Sobald ein DolP-Paket an dem Schalter 302 ankommt, wird eine TCAM-Regel (TCAM: Ternary Content-Addressable Memory) implementiert, um diese Art von Paketen zu einer spezifischen Reihe zu senden, die mit der Schalter-CPU 304 verbunden ist. Dieses Paket wird in der Firewall auf der CPU analysiert und dann zu den DoIP-Kantenknoten, d. h. zu dem Mikrocontroller 320 des Leitrechners, geleitet. Der Datenpfad (Pfeile 350) zwischen dem Diagnoseanschluss 342 und dem DoIP-Kantenknoten, dem Mikrocontroller 320 des Leitrechners, kann in der 4 gesehen werden. Die Pfeile 350 zeigen somit den Datenverkehrsfluss zwischen dem Tester 340 und dem Mikrocontroller 320 des Leitrechners in beide Richtungen. Wenn der Tester 340 mit dem Mikrocontroller 320 des Leitrechners über DolP kommunizieren möchte, gehen die Daten von dem Tester 340 auf einem bestimmten bzw. gewissen Schalteranschluss zu der Schalter-CPU 304 und die Schalter-CPU 304 verfügt über eine Firewall, die überprüft, ob dieses Paket erlaubt ist oder nicht. Wenn das Paket erlaubt ist, dann leitet die Schalter-CPU 304 dieses zu dem Anschluss, mit dem der Mikrocontroller 320 des Leitrechners verbunden ist. Auf dem Weg zurück von dem Mikrocontroller 320 des Leitrechners wird der Mikrocontroller 320 des Leitrechners immer als vertrauensvolle Quelle betrachtet, daher muss das Paket nicht durch eine Firewall geleitet werden und kann direkt zu dem Tester 340 geleitet werden, ohne durch die Schalter-CPU 304 geführt zu werden.
  • In der Darstellung bezeichnen weiterhin Pfeile 360 den Datenverkehr von allen VLANs zu der internen CPU über eine 2BGit-Schnittstelle, um Entscheidungen hinsichtlich Firewall und Leiten bzw. Routing treffen zu können. Ein erster Doppelpfeil bezeichnet eine Standard-Datenreihe, ein zweiter Doppelpfeil 364 bezeichnet eine Datenreihe für Wartung und Aktualisierung, ein dritter Doppelpfeil 364 bezeichnet eine DoIP-Paketreihe.
  • Zu berücksichtigen ist, dass Ethernet-Schalter eine MAC-Adresstabelle (MAC: Media Access Address) haben, die auch als Adressumsetzungstabelle (ATU: Adress Translation Unit) bezeichnet wird, die MAC-Adressen und Anschlussnummern enthält. Schalter folgen diesem einfachen Algorithmus, um Pakete weiterzuleiten. Die MAC-Adresse ist dabei eine Hardware-Adresse, die als eindeutiger Identifikator eines Geräts in einem Netzwerk dient.
  • Wenn ein Rahmen empfangen wird, vergleicht der Schalter die Quell-MAC-Adresse mit der MAC-Adresstabelle. Wenn die Quelle unbekannt ist, fügt der Schalter diese zu der Tabelle hinzu, zusammen mit der Nummer des Anschlusses, bei dem das Paket empfangen wurde. Auf diese Weise lernt der Schalter die MAC-Adresse und den Anschluss für jede übertragende Komponente.
  • Der Schalter vergleicht dann die Ziel-MAC-Adresse mit der Tabelle. Wenn es einen Eintrag gibt, leitet der Schalter den Rahmen aus dem zugeordneten Anschluss weiter, wenn kein Eintrag vorliegt, sendet der Schalter das Paket an alle Anschlüsse, außer an den Anschluss, von dem der Rahmen empfangen wurde, was als Überfluten bzw. Flooding bezeichnet wird.
  • Bei einem Standard-Ethernet-Schalter wird die ATU-Datenbank gemeinsam von allen Schalteranschlüssen verwendet. Dies bedeutet, wenn ein Angreifer mehrere falsche MAC-Adressen an den Diagnoseanschluss sendet, wird dieser die MAC-Tabellen-Datenbank vollständig überschreiben. Dies wird eine unvorhersehbare Situation in dem Fahrzeugnetzwerk herbeiführen, das das Kommunikationsnetzwerk davon beeinträchtigt wird.
  • In einem intelligenten Ethernet-Schalter ist die ATU-Datenbank nicht gemeinschaftlich, anstelle dessen gibt es eine getrennte ATU-Datenbank für jeden Anschluss. Auf diese Weise ist sichergestellt, dass, wenn ein Angreifer falsche MAC-Adressen an den Diagnoseanschluss sendet, nur dieser Diagnoseanschluss betroffen sein wird. Andere Kommunikationsanschlüsse werden davon überhaupt nicht beeinflusst sein und die Fahrzeugkommunikation wird wie bislang weiter fortgesetzt. Dieses Merkmal wird bei der vorgestellten sicheren Diagnoselösung verwendet.
  • Eine anschlussbasierte Ratenbegrenzung ermöglicht es einem Nutzer, die Geschwindigkeit zu begrenzen, bei der der Netzwerkverkehr durch eine Komponente gesendet oder empfangen wird, die mit einem Anschluss auf einem intelligenten Schalter verbunden ist. Anders als bei 802.1P-Qualität des Dienstes (QoS) priorisiert eine anschlussbasierte Ratenbegrenzung nicht die Information basierend auf der Art. 802.1p stelle einen IEEE-Standard für die Qualität von Diensten im Ethernet-Verkehr dar. Dies ermöglicht es dem Nutzer, einige Pakete eine hohe Priorität und anderen Paketen eine niedrige Priorität zuzuweisen. Dieser werden dann entsprechend durch den Schalter behandelt. Eine Ratenbegrenzung bedeutet lediglich, dass der Schalter den Verkehr auf einem Anschluss verlangsamen wird, um diesen davon abzuhalten, die Begrenzung, die vorgegeben ist, zu übersteigen. Wenn die Ratenbegrenzung auf einem Anschluss zu gering gesetzt ist, sind ggf. eine verschlechterte Videostream-Qualität, eine langsame Reaktionszeit während der Online-Aktivität und andere Probleme zu betrachten.
  • Dieses Merkmal in dem Schalter kann verwendet werden, um eine Sicherheit bei dem Diagnoseanschluss zu erreichen. Als Teil des DoIP-Kommunikationsschritts, der in 3 gezeigt ist, bevor ein sicherer TLS-Tunnel erzeugt wird, gibt es eine antwortbasierte angestrebte Authentifizierung, die zwischen dem DolP-Kantenknoten und dem Tester durchgeführt wird. Es gibt eine begrenzte Datenmenge, die zwischen dem Tester und dem DolP-Kantenknoten übertragen wird, bevor der sichere TLS-Tunnel erzeugt wurde. Es könnte daher eine sichere Lösung sein, die Rate des Diagnoseanschlusses auf eine sehr geringe Geschwindigkeit zu begrenzen, bspw. 64 KBit/s anstelle von vollen 100 Mbit/s. Die Ratenbegrenzung muss lediglich ausreichend für die anfänglichen Schritte sein. Dies wird die Fähigkeit eines Angreifers darin einschränken, den kompromittierten Diagnoseanschluss zu verwenden und damit zu beginnen, Daten bei einer sehr hohen Rate zu übertragen, um eine Verweigerung von Diensten oder ähnliches zu erreichen.
  • Sobald der sichere TLS-Tunnel zwischen dem Tester und dem DoIP-Kantenknoten erzeugt wurde, informiert der Mikrocontroller des Leitrechners die Schalter-CPU, dass nunmehr ein sicherer Verbindungstunnel vorliegt und fragt an, um eine Datenübertragung mit hoher Bandbreite zu ermöglichen. Nach einer Anfrage von dem Mikrocontroller des Leitrechners stellt die Schalter-CPU die volle Kommunikationsbandbreite auf dem Diagnoseanschluss bereit. Wenn wiederum die Kommunikation durchgeführt wurde, wird der Tunnel geschlossen. Der Mikrocontroller des Leitrechners fragt bei der Schalter-CPU an, die Kommunikationsbandbreite auf eine sehr geringe Geschwindigkeit zu verringern.
  • TLS (Transport Layer Security) ist ein kryptographisches Protokoll, das eine Kommunikationssicherheit zwischen Netzwerk-Endknoten bereitstellt. Die nachstehend genannten Größen sind Grundgrößen von TLS, die sicherstellen, dass der Tunnel sicher ist. Der Tunnel versucht vornehmlich, Geheimhaltung und Datenintegrität zwischen zwei Kommunikationsanwendungen sicherzustellen. Wenn Verbindungen zwischen einem Klienten und einem Server durch TLS gesichert werden, haben diese eine oder mehrere der folgenden Größen:
  • Die Verbindung ist privat oder sicher, da eine symmetrische Verschlüsselung verwendet wird, um die übertragenen Daten zu verschlüsseln. Die Schlüssel für diese symmetrische Verschlüsselung werden einmalig für jede Verbindung erzeugt und basieren auf einem gemeinsamen Geheimnis, das zu Beginn der Sitzung, dem sogenannten TLS-Handshake, ausgehandelt bzw. vereinbart wurde. Der Server und der Klient verhandeln die Details, welcher Verschlüsselungsalgorithmus und welche kryptographischen Schlüssel verwendet werden, bevor das erste Datenbyte übertragen wird. Die Vereinbarung eines gemeinsamen Geheimnisses ist sowohl sicher, das vereinbarte Geheimnis ist für Lauscher nicht zugänglich und kann nicht erhalten werden, selbst durch einen Angreifer, der sich mitten in die Verbindung setzt, als auch zuverlässig, kein Angreifer kann die Kommunikationen während der Vereinbarung modifizieren, ohne erkannt zu werden.
  • Die Identität der kommunizierenden Parteien kann authentifiziert werden, wobei eine Verschlüsselung mit öffentlichem Schlüssel verwendet wird. Diese Authentifizierung kann optional vorgesehen sein. Allerdings sollte diese grundsätzlich für eine der beiden Parteien, typischerweise den Server, erforderlich sein.
  • Die Verbindung sichert Integrität, da jede übertragene Nachricht eine Nachricht-Integrität-Überprüfung umfasst, wobei ein Nachricht-Authentifizierungscode verwendet wird, um einen nicht erfassten Verlust oder eine Änderung der Daten bei der Übertragung zu verhindern.
  • Die vorgestellte Lösung sichert die Fahrzeugdiagnose auf einem sehr hohen Level. Alle Schritte des Verfahrens in Ausgestaltung können wie folgt in nachstehenden Schritten zusammengefasst werden:
    1. 1. Ein separater bzw. getrennter Kommunikationspfad wird zwischen dem Diagnoseanschluss und dem DolP-Kantenknoten erzeugt, der durch die Firewall reicht. Dies verwendet eine getrennte Reihe zwischen dem Schalterkern und der Schalter-CPU und verwendet eine separate MAC-Adresstabellen-Datenbank pro Anschluss.
    2. 2. Die Bandbreite des Diagnoseanschlusses wird auf eine sehr geringe Zugangsgeschwindigkeit gesetzt, so dass ein Angreifer nicht zu viele Daten an den Anschluss senden kann.
    3. 3. Der Tester verbindet sich mit dem Diagnoseanschluss des Schalters und versucht, eine Verbindung anzufragen.
    4. 4. Der DolP-Kantenknoten antwortet dem Tester zu verfügbaren Verbindungen.
    5. 5. Eine Herausforderungsantwort wird zwischen dem Tester und dem DoIP-Kantenknoten gegeben und der Tester wird authentifiziert.
    6. 6. Ein sicherer TLS-Tunnel zur Kommunikation wird zwischen dem DoIP-Kantenknoten und dem Tester erzeugt.
    7. 7. Der Mikrocontroller des Leitrechners fragt bei der Schalter-CPU an, dem Diagnoseanschluss die volle Bandbreite zuzuweisen und daher weist die Schalter-CPU die volle Bandbreite de Anschluss zu.
    8. 8. Eine sichere Diagnosedaten-Kommunikation wird zwischen dem Tester und dem DolP-Kantenknoten bei voller Bandbreite vorgenommen.
    9. 9. Der sichere TLS-Tunnel wird beendet, nachdem die Kommunikation abgeschlossen ist, und der Mikrocontroller des Leitrechners fragt bei der Schalter-CPU an, die Bandbreite wiederum am Diagnoseanschluss zu verringern.
    10. 10. Gehe zu Schritt 2.
  • Bei gewissen Ausführungen kann vorgesehen sein, dass der TLS-Tunnel auch zwischen dem Tester und der Schalter-CPU eingerichtet wird, wenn die Schalter-CPU über eine Software verfügt, die für DolP-Kommunikationen zu anderen Steuergeräten in dem Fahrzeug eingerichtet ist und eine TLS-Bibliothek hat. Auf ähnliche Weise kann das Konzept der Ratenbegrenzung an dieser Stelle ebenfalls angewendet werden.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • DE 102015214423 A1 [0007]

Claims (10)

  1. Verfahren zum Durchführen einer Diagnose in einem Fahrzeug, bei dem mit einem externen Tester (200, 340) über einen Diagnoseanschluss (342) auf eine Komponente des Fahrzeugs zugegriffen wird, wobei der Zugriff über ein Gateway (300), das den Diagnoseanschluss (342) und einen Schalter (302) aufweist, erfolgt, wobei der Schalter (302) einen Schalter-Kern (308) und eine Schalter-CPU (304) umfasst, wobei im Rahmen der Diagnose Daten zu und von einem Mikrocontroller (320) eines Leitrechners übertragen werden, wobei bei dem Verfahren zunächst eine Verbindung zwischen dem Tester (340) und dem Diagnoseanschluss (342) aufgebaut wird, wobei hierbei eine verringerte Datenrate durch den Schalter (302) eingestellt wird, bis ein sicherer Datentunnel aufgebaut ist.
  2. Verfahren nach Anspruch 1, bei dem die Verbindung zwischen dem Tester (340) und der Schalter-CPU (304) aufgebaut wird.
  3. Verfahren nach Anspruch 1 oder 2, bei dem der Schalter (302) von dem Mikrocontroller (320) eines Leitrechners darüber informiert wird, dass ein sicherer Datentunnel aufgebaut ist.
  4. Verfahren nach einem der Ansprüche 1 bis 3, bei dem Daten zusätzlich über eine Firewall geleitet werden.
  5. Verfahren nach einem der Ansprüche 1 bis 4, bei dem der Tester (340) für die Verbindungsanfrage eine Anfrage an den Diagnoseanschluss (342) stellt und der Diagnoseanschluss (342) hierauf eine Antwort an den Tester (340) sendet.
  6. Verfahren nach einem der Ansprüche 1 bis 5, bei dem ein TLS-Datentunnel aufgebaut wird.
  7. Verfahren nach einem der Ansprüche 1 bis 6, bei dem nach Abschluss der Diagnose die Datenrate für den Diagnoseanschluss (342) wieder verringert wird.
  8. Anordnung zum Durchführen einer Diagnose in einem Fahrzeug, die zur Durchführung eines Verfahrens nach einem der Ansprüche 1 bis 7 eingerichtet ist.
  9. Computerprogramm mit Programmcodemitteln, das dazu eingerichtet ist, ein Verfahren nach einem der Ansprüche 1 bis 7 auszuführen, wenn das Computerprogramm auf einer Recheneinheit, insbesondere einer Recheneinheit in einer Anordnung gemäß Anspruch 8, ausgeführt wird.
  10. Maschinenlesbares Speichermedium mit einem darauf gespeicherten Computerprogramm nach Anspruch 9.
DE102018202996.2A 2018-02-28 2018-02-28 Verfahren zum Durchführen einer Diagnose Pending DE102018202996A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE102018202996.2A DE102018202996A1 (de) 2018-02-28 2018-02-28 Verfahren zum Durchführen einer Diagnose
CN201910145088.9A CN110213221B (zh) 2018-02-28 2019-02-27 用于执行诊断的方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102018202996.2A DE102018202996A1 (de) 2018-02-28 2018-02-28 Verfahren zum Durchführen einer Diagnose

Publications (1)

Publication Number Publication Date
DE102018202996A1 true DE102018202996A1 (de) 2019-08-29

Family

ID=67550177

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102018202996.2A Pending DE102018202996A1 (de) 2018-02-28 2018-02-28 Verfahren zum Durchführen einer Diagnose

Country Status (2)

Country Link
CN (1) CN110213221B (de)
DE (1) DE102018202996A1 (de)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20210120287A (ko) * 2020-03-26 2021-10-07 현대자동차주식회사 진단 시스템 및 차량
CN111736578B (zh) * 2020-08-14 2020-12-08 广州汽车集团股份有限公司 一种基于双cpu控制器的uds诊断方法及装置
CN112821994B (zh) * 2020-12-31 2022-05-17 武汉光庭信息技术股份有限公司 一种双冗余ecu的uds响应调停系统及方法
CN112859814B (zh) * 2021-01-19 2022-08-02 英博超算(南京)科技有限公司 一种异构平台的DoIP诊断系统
CN115065699B (zh) * 2022-06-08 2024-06-07 深圳市元征科技股份有限公司 基于远程诊断的路由激活方法、装置、设备及介质

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8036788B2 (en) * 1995-06-07 2011-10-11 Automotive Technologies International, Inc. Vehicle diagnostic or prognostic message transmission systems and methods
US20020150050A1 (en) * 1999-06-17 2002-10-17 Nathanson Martin D. Automotive telemetry protocol
GB2392983A (en) * 2002-09-13 2004-03-17 Bombardier Transp Gmbh Remote system condition monitoring
DE102008035557A1 (de) * 2008-07-30 2010-02-04 Bayerische Motoren Werke Aktiengesellschaft Verfahren zum Einbringen von Daten, insbesondere eine Ablaufsteuerung, in mindestens ein erstes und ein zweites Steuergerät eines Kraftfahrzeugs
CN101751033A (zh) * 2008-12-01 2010-06-23 北京经纬恒润科技有限公司 车辆远程监测诊断系统及方法
US8983681B2 (en) * 2011-10-06 2015-03-17 General Motors Llc Method of communicating with a vehicle having a telematics unit
DE102012208205A1 (de) * 2012-05-16 2013-11-21 Bayerische Motoren Werke Aktiengesellschaft Datenlogging bzw. Stimulation in Automotiven Ethernet Netzwerken unter Verwendung der Fahrzeug-Infrastruktur
DE102013217259A1 (de) * 2013-08-29 2015-03-05 Bayerische Motoren Werke Aktiengesellschaft Modusumschaltung eines Steuergeräts zwischen Diagnosebus und externer Ethernetverbindung
EP3167436B1 (de) * 2014-07-11 2022-03-16 Entrust, Inc. Verfahren und vorrichtung zur bereitstellung von fahrzeugsicherheit
FR3033429B1 (fr) * 2015-03-04 2018-08-03 Continental Automotive France Microcontroleur avec un module de diagnostic et procede d'acces audit module dudit microcontroleur
CN206178464U (zh) * 2016-11-04 2017-05-17 上海迪璞电子科技股份有限公司 一种基于ARM Cortex的多协议车辆诊断系统
CN106685985B (zh) * 2017-01-17 2019-11-29 同济大学 一种基于信息安全技术的车辆远程诊断系统及方法
CN107472169B (zh) * 2017-07-31 2019-07-09 北京新能源汽车股份有限公司 电动汽车的控制系统和汽车

Also Published As

Publication number Publication date
CN110213221A (zh) 2019-09-06
CN110213221B (zh) 2023-08-11

Similar Documents

Publication Publication Date Title
DE102018202996A1 (de) Verfahren zum Durchführen einer Diagnose
DE102014224694B4 (de) Netzwerkgerät und Netzwerksystem
DE102014113582B4 (de) Vorrichtung, Verfahren und System für die kontextbewusste Sicherheitssteuerung in einer Cloud-Umgebung
DE112019000485T5 (de) System und verfahren zum bereitstellen der sicherheit für einfahrzeuginternes netzwerk
DE10393526T5 (de) System und Verfahren für IEEE 802.1X Benutzerauthentifizierung in einem Netzzutrittsgerät
WO2006133774A1 (de) Verfahren und vorrichtung zum sicheren kommunizieren einer komponente eines fahrzeugs über eine drahtlose kommunikationsverbindung mit einem externen kommunikationspartner
DE102015122518A1 (de) Authentifizierung von Datenkommunikationen
DE102017221889A1 (de) Datenverarbeitungseinrichtung, Gesamtvorrichtung und Verfahren zum Betrieb einer Datenverarbeitungseinrichtung oder Gesamtvorrichtung
DE102021203094A1 (de) Kommunikationsnetzwerksystem für Fahrzeuge sowie dessen Betriebsverfahren
EP3105898B1 (de) Verfahren zur kommunikation zwischen abgesicherten computersystemen sowie computernetz-infrastruktur
EP3318033B1 (de) Anti-cracking verfahren mit hilfe eines vermittlungscomputer
DE102017212474A1 (de) Verfahren und Kommunikationssystem zur Überprüfung von Verbindungsparametern einer kryptographisch geschützten Kommunikationsverbindung während des Verbindungsaufbaus
EP3152880B1 (de) Verfahren zur kommunikation zwischen abgesicherten computersystemen, computernetz-infrastruktur sowie computerprogramm-produkt
EP3556071B1 (de) Verfahren, vorrichtung und computerlesbares speichermedium mit instruktionen zum signieren von messwerten eines sensors
EP3170295B1 (de) Erhöhen der sicherheit beim port-knocking durch externe computersysteme
DE102017202239A1 (de) Verfahren und Vorrichtung zum Vereinbaren eines gemeinsamen Schlüssels zwischen einem ersten Knoten und einem zweiten Knoten eines Rechnernetzes
EP3682317B1 (de) Verfahren zum betrieb einer berührungssensitiven, flächigen eingabevorrichtung einer gesamtvorrichtung und gesamtvorrichtung
DE202021102465U1 (de) Einarmiger Inline-Entschlüsselungs-/Verschlüsselungsproxy, der im Modus einer transparenten Bridge arbeitet
DE102022107431B3 (de) Verfahren zum Nachrüsten einer Socks-Kompatibilität für zumindest eine Anwendung in einem Kraftfahrzeug sowie entsprechend eingerichtetes Kraftfahrzeug
DE102014102627B3 (de) Arbeitsverfahren für ein System sowie System
DE102020204059A1 (de) Verfahren zur Behandlung einer Anomalie von Daten, insbesondere bei einem Kraftfahrzeug
DE102020006075A1 (de) Verfahren zur Absicherung von gespeicherten Nutzdaten
DE102017202602A1 (de) Verfahren und Vorrichtung zum Betreiben eines Steuergerätes an einem Bus
DE102019214409A1 (de) Vorrichtung und Verfahren für den Zugriff auf Feldgeräte in der Automatisierungstechnik
EP4120624A1 (de) Verfahren und automatisierungssystem zur einbindung eines automatisierungsgeräts

Legal Events

Date Code Title Description
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0012260000

Ipc: H04L0043000000