DE102022209780A1

DE102022209780A1 - Sichere ethernet-basierte kommunikation zwischen zwei controller area networks (can)

Info

Publication number: DE102022209780A1
Application number: DE102022209780.7A
Authority: DE
Inventors: Ronnie Stirn; Manuel Jauss; Felix Hallaczek; Marcel Kneib
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2022-09-16
Filing date: 2022-09-16
Publication date: 2024-03-21
Also published as: CN117728968A

Abstract

Ein erster Aspekt der vorliegenden Offenbarung betrifft ein computer-implementiertes Verfahren zum Übertragen von Controller Area Network Frames aus einem ersten Controller Area Network (CAN) in ein zweites Controller Area Network, umfassend Empfangen, in einer ersten Recheneinheit des ersten Controller Area Network, mindestens eines ersten CAN-Frame aus dem ersten Controller Area Network; Transformieren des mindestens einen ersten CAN-Frame in ein Ethernet-Frame, wobei Daten zumindest in einem ersten Teil eines Nutzlastfeldes des Ethernet-Frame zumindest Daten eines Nutzlastfeldes des mindestens einen ersten CAN-Frame codieren; Senden, via ein Ethernet und basierend auf einem kryptographischen Netzwerkprotokoll, des Ethernet-Frame an eine erste Recheneinheit des zweiten Controller Area Network.Ein zweiter Aspekt der vorliegenden Offenbarung betrifft ein computer-implementiertes Verfahren zum Empfangen von Controller Area Network Frames aus einem ersten Controller Area Network (CAN) in einem zweiten Controller Area Network, umfassend Empfangen, in einer ersten Recheneinheit des zweiten Controller Area Network und via ein Ethernet und basierend auf einem kryptographischem Netzwerkprotokoll, eines Ethernet-Frame, das von einer ersten Recheneinheit des ersten Controller Area Network gesendet worden ist, wobei zumindest Daten in einem ersten Teil eines Nutzlastfeldes des Ethernet-Frame zumindest Daten eines Nutzlastfeldes des mindestens einen ersten CAN-Frame aus dem ersten Controller Area Network codieren; Transformieren des Ethernet-Frame in mindestens ein zweites CAN-Frame des zweiten Controller Area Network, wobei Daten in einem Nutzlastfeld des mindestens einen zweiten CAN-Frame auf Daten in einem Nutzlastfeld des mindestens einen ersten CAN-Frame basieren.

Description

Stand der Technik
Ethernet ist eine bekannte Klasse von Computer-Netzwerktechnologien für die Kommunikation in kabelgebundenen Datennetzen, insbesondere in lokalen Datennetzen (englisch: local area network, LAN). Ein Ethernet der Klasse spezifiziert das Übertragungsmedium sowie Übertragungsformen/Protokolle auf üblicherweise verschiedenen Schichten im OSI-Modell (englisch: open systems interconnection model, OSI model). Im OSI-Modell ist mit Ethernet sowohl die physische Schicht (OSI-Layer 1) als auch die Data-Link-Schicht (OSI-Layer 2) festgelegt. Ethernet kann durch die IEEE 802.3 Normen definiert sein.
Ein Controller Area Network (CAN), in dem Recheneinheiten, insbesondere Steuergeräte, eines technischen Systems (z.B. eines Fahrzeugs oder eines Teils davon) über einen CAN-Bus verbunden sind und gemäß einem CAN-Protokoll miteinander kommunizieren können, stellt ein bekanntes und standardisiertes serielles Bussystem nach dem Multi-Master-Prinzip dar, in dem alle Steuergeräte im CAN gleichberechtigt sind. Beispielsweise können CAN (mittlerweile in verschiedenen Versionen) und/oder auf CAN-inspirierte Weiterentwicklungen in mechatronischen technischen Systemen aller Art (z.B. in der Automobilindustrie, in der Automatisierungstechnik, bei Aufzugsanlagen, in der Medizintechnik, in der Luft- und Raumfahrttechnik, im Schienenfahrzeugbau, im Schiffbau, ...) zum Einsatz kommen.
CAN und/oder CAN-inspirierte Weiterentwicklungen (abgekürzt als CAN etc.) wurden und werden derart entwickelt, dass die Datenübertragung über den CAN-Bus möglichst unabhängig von äußeren zufälligen Störungen (z.B. im Sinne der EMV) ist. Beispielsweise kann der CAN-Bus durch zwei verdrillte Adern (CAN_HIGH, CAN_LOW) realisiert werden und somit eine symmetrische Signalübertragung erreicht werden. Dadurch haben sich CAN etc. insbesondere auch in sicherheitsrelevanten Bereichen (z.B. im Fahrzeug) bewährt, bei denen es auf hohe Datensicherheit ankommt.
An solche technischen Systeme werden häufig weitere zu erfüllende Sicherheitsanforderungen gestellt.
Die Sicherheitsanforderungen umfassen in den sicherheitsrelevanten Bereichen (z.B. im Fahrzeug) sogenannte safety-Anforderungen, d.h. zum Beispiel Anforderungen der funktionalen Sicherheit gemäß der derzeit gängigen Norm IEC 61508 und/oder, speziell für Fahrzeuge, gemäß der gängigen Norm ISO 26262. Die safety-Anforderungen können darauf gerichtet sein, zufällige Änderungen von zu übertragenden Daten zu erkennen. Die safety-Anforderungen sind somit auf die Integrität der zu übertragenden Daten gerichtet. Im Gegensatz zu Ethernet sind für CAN etc. Verfahren etabliert, die die Anforderungen der funktionalen Sicherheit erfüllen. Dazu kann zum Beispiel eine Blockprüfzeichenfolge, z.B. eine zyklische Redundanzprüfung, englisch: cyclic redundancy check (CRC), in einem CAN-Frame mit den innerhalb des CAN etc. zu übertragenden Daten implementiert werden. Des Weiteren ist Kommunikation über CAN etc. im Gegensatz zu Ethernet auch ohne Protokollerweiterungen echtzeitfähig.
Die Sicherheitsanforderungen können insbesondere in den sicherheitsrelevanten Bereichen (z.B. im Fahrzeug) auch sogenannte security-Anforderungen umfassen. Security-Anforderungen können darauf gerichtet sein, gezielte Manipulationen von zu übertragenden Daten zu erkennen. Zum Beispiel können die Security-Anforderungen darauf gerichtet sein, die Authentizität und Integrität von zu übertragenden Daten zu gewährleisten. Zu übertragende Daten sind authentisch, wenn der tatsächliche Absender der zu übertragenden Daten mit dem angegebenen Absender übereinstimmt. Zu übertragende Daten sind integer, wenn sie ausgehend vom eigentlichen Absender nicht (gezielt) geändert worden sind. Der Nachweis von Authentizität und Integrität kann über Nachrichtenauthentifizierungscodealgorithmen via Nachrichtenauthentifizierungscodes (englisch: message authentication code, MAC) erbracht werden. Bekannte Nachrichtenauthentifizierungscodealgorithmen sind zum Beispiel cipher-based MAC (CMAC) und hash-based MAC (HMAC). Security-Anforderungen können weiterhin darauf gerichtet sein, die Vertraulichkeit der zu übertragenden Daten zu gewährleisten. Dazu können zum Beispiel bekannte Verschlüsselungsalgorithmen zum Einsatz kommen.
Offenbarung der Erfindung
Ein erster allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein computer-implementiertes Verfahren zum Übertragen von Controller Area Network Frames (mindestens eines Controller Area Network Frame) aus einem ersten Controller Area Network (CAN) in ein zweites Controller Area Network. Das Verfahren kann Empfangen, in einer ersten Recheneinheit des ersten Controller Area Network, mindestens eines ersten CAN-Frame aus dem ersten Controller Area Network, umfassen. Das Verfahren umfasst weiterhin Transformieren des mindestens einen ersten CAN-Frame in ein Ethernet-Frame, wobei Daten zumindest in einem ersten Teil eines Nutzlastfeldes des Ethernet-Frame zumindest Daten eines Nutzlastfeldes des mindestens einen ersten CAN-Frame codieren. Das Verfahren umfasst Senden, via ein Ethernet (d.h. zum Beispiel via Ethernet oder via einem Ethernet-Netzwerk) und basierend auf einem kryptographischen Netzwerkprotokoll, des Ethernet-Frame an eine erste Recheneinheit des zweiten Controller Area Network.
Ein zweiter allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein computer-implementiertes Verfahren zum Empfangen von Controller Area Network Frames (mindestens eines Controller Area Network Frame) aus einem ersten Controller Area Network (CAN) in einem zweiten Controller Area Network. Das Verfahren umfasst Empfangen, in einer ersten Recheneinheit des zweiten Controller Area Network und via ein Ethernet und basierend auf einem kryptographischem Netzwerkprotokoll, eines Ethernet-Frame, das von einer ersten Recheneinheit des ersten Controller Area Network gesendet worden ist, wobei zumindest Daten in einem ersten Teil eines Nutzlastfeldes des Ethernet-Frame zumindest Daten eines Nutzlastfeldes des mindestens einen ersten CAN-Frame aus dem ersten Controller Area Network codieren. Das Verfahren umfasst weiterhin Transformieren des Ethernet-Frame in mindestens ein zweites CAN-Frame des zweiten Controller Area Network, wobei Daten in dem Nutzlastfeld des mindestens einen zweiten CAN-Frame auf Daten in dem Nutzlastfeld des mindestens einen ersten CAN-Frame basieren.
Ein dritter allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein computer-implementiertes Verfahren, das das computer-implementierte Verfahren zum Übertragen von Controller Area Network Frames aus dem ersten Controller Area Network (CAN) in das zweites Controller Area Network nach dem ersten allgemeinen Aspekt (oder einer Ausführungsform davon) umfasst. Das Verfahren umfasst weiterhin das computer-implementierte Verfahren zum Empfangen von Controller Area Network Frames aus dem ersten Controller Area Network (CAN) in dem zweiten Controller Area Network nach dem zweiten allgemeinen Aspekt (oder einer Ausführungsform davon).
Ein vierter allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein Computer-System, insbesondere eine Recheneinheit eines Controller Area Network, das dafür ausgelegt ist, das Verfahren nach dem ersten allgemeinen Aspekt (oder einer Ausführungsform davon) auszuführen. Alternativ oder zusätzlich kann das Computer-System dafür ausgelegt sein, das Verfahren nach dem zweiten allgemeinen Aspekt (oder einer Ausführungsform davon) auszuführen. Alternativ oder zusätzlich kann das Computer-System dafür ausgelegt sein, das Verfahren nach dem dritten allgemeinen Aspekt (oder einer Ausführungsform davon) auszuführen.
Ein fünfter allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein Computer-Programm, das dafür ausgelegt ist, das Verfahren nach dem ersten allgemeinen Aspekt (oder einer Ausführungsform davon) auszuführen. Alternativ oder zusätzlich kann das Computer-Programm dafür ausgelegt sein, das Verfahren nach dem zweiten allgemeinen Aspekt (oder einer Ausführungsform davon) auszuführen. Alternativ oder zusätzlich kann das Computer-Programm dafür ausgelegt sein, das Verfahren nach dem dritten allgemeinen Aspekt (oder einer Ausführungsform davon) auszuführen.
Ein sechster allgemeiner Aspekt der vorliegenden Offenbarung betrifft ein computer-lesbares Medium oder Signal, das das Computer-Programm nach dem fünften allgemeinen Aspekt (oder einer Ausführungsform davon) speichert und/oder enthält.
Die in dieser Offenbarung vorgeschlagenen Verfahren nach dem ersten, zweiten und/oder dritten Aspekt (oder jeweils einer Ausführungsform davon) sind darauf gerichtet, eine sichere Ethernet-basierte Kommunikation zwischen zwei Controller Area Networks (CAN) zu ermöglichen. Die Verfahren sind insbesondere darauf gerichtet, Daten sicher von dem ersten Controller Area Network über das Ethernet in das zweite Controller Area Network zu übertragen. Dabei können die oben beschriebenen safety- und, optional, security-Anforderungen an die Kommunikation in einem sicherheitsgerichteten technischen System, wie zum Beispiel in einem Fahrzeug, eingehalten werden, obwohl für das Ethernet an sich ein Nachweis zumindest der safety-Anforderungen nicht erbracht werden kann. Weiterhin kann die security-Anforderung der Authentizität und Integrität der zu übertragenden Daten eingehalten werden. Die security-Anforderung der Vertraulichkeit der zu übertragenden Daten kann, muss aber nicht eingehalten werden.
Weiterhin können Daten im Ethernet basierend auf einem Übertragungszeitgarantieprotokoll, insbesondere basierend auf einem Protokoll zur Gewährleistung echtzeitfähiger Kommunikation, gesendet und/oder empfangen werden. Dadurch können zusätzliche Echtzeitanforderungen an die Datenübertragung erfüllt werden. Das Übertragungszeitgarantieprotokoll, insbesondere das Protokoll zur Gewährleistung echtzeitfähiger Kommunikation, kann zum Beispiel ein Time Sensitive Networking (TSN) Standard der IEEE 802.1 Familie sein.
Das technische System kann ein mechatronisches technisches System z.B. in der Automobilindustrie, in der Automatisierungstechnik, bei Aufzugsanlagen, in der Medizintechnik, in der Luft- und Raumfahrttechnik, im Schienenfahrzeugbau, im Schiffbau, etc. sein. Das technische System kann insbesondere ein Fahrzeug, insbesondere mit safety- und security-Anforderungen an die Datenkommunikation, sein.
Die in dieser Offenbarung vorgeschlagenen Verfahren sind besonders vorteilhaft, wenn das technisches System, insbesondere das Fahrzeug, ohnehin (d.h. aus anderen Gründen) ein Ethernet aufweisen soll. In der Tat ist bereits zum Beispiel in vielen neueren Fahrzeugen Ethernet implementiert bzw. vorgesehen. In solchen Fällen kann durch die Verwendung bestehender Ethernetleitungen der Bedarf an zusätzlichen CAN-Leitungen reduziert werden, wodurch Gewicht und Kosten gespart werden. Das Vorhandensein eines bereits im technischen System ausgebreiteten Ethernet erlaubt dank der in dieser Offenbarung vorgeschlagenen Verfahren insbesondere die Aufteilung eines sicherheitsgerichteten Controller Area Network in zwei oder mehrere sicherheitsgerichtete Controller Area Networks, die dann jeweils untereinander über das Ethernet sicher kommunizieren können.
Die Lösung basiert auf der Verwendung einer Kombination aus etablierten und standardisierten Protokollen, wodurch die Wiederverwendung bestehender und bereits erprobter Komponenten ermöglicht wird. Dadurch können weitere Kosten gespart werden.
Die in dieser Offenbarung vorgeschlagenen Verfahren ermöglichen insbesondere eine Ende-zu-Ende abgesicherte Übertragung von safety- und, optional, securityrelevanter CAN-Frames via Ethernet über beliebige Knoten, Vertrauenszonen oder (Fahrzeug-)Domänen hinweg. Für Recheneinheiten/Steuergeräte, die als Ethernet-Knoten (auch: Hop) dienen, fallen dabei dennoch keine zusätzlichen safety-Anforderungen an. Dies gilt sowohl für Recheneinheiten/Steuergeräte unterschiedlicher Vertrauenszonen (Steuergeräte werden aufgrund von Safety- und/oder Security-Anforderungen in Vertrauenszonen eingeteilt, die durch Vertrauensgrenzen, englisch: trust boundaries, voneinander abgegrenzt werden), als auch für Steuergeräte unterschiedlicher räumlicher Fahrzeugzonen in einer zonalen E/E-Architektur. Die Aufspaltung eines einzelnen CAN etc. des technischen Systems in mehrere CAN etc., die jeweils über ein/das Ethernet kommunizieren, ermöglicht die Implementierung eines Vertrauenszonentrennungskonzept.
Ein weiterer Vorteil gegenüber zum Beispiel der Verwendung von AUTOSAR SecOC in einem einzelnen größeren CAN etc. liegt in der effizienteren Bandbreitennutzung bei gleichzeitiger Erhöhung des Sicherheitsniveaus. Während bei High Speed CAN mit AUTOSAR SecOC die Hälfte der Nutzlast für einen trunkierten Nachrichtenauthentifizierungscode (englisch: message authentication code, MAC) verwendet werden muss (z.B. 64 Bit Nutzlast, 32 Bit trunkierter Nachrichtenauthentifizierungscode), ermöglicht die größere Nutzlast des Ethernet-Protokolls die Übertragung des vollständigen, d.h. des untrunkierten, Nachrichtenauthentifizierungscode. Durch die größere zur Verfügung stehende Nutzlast im Ethernet Frame verbessert sich trotz des längeren Nachrichtenauthentifizierungscode das Nutzlast-zu-MAC-Verhältnis.
Die Verfahren können zum Beispiel auf einer Kombination aus etablierten und standardisierten Protokollen zum Aufbau eines Tunnels über mehrere weniger vertrauenswürdige Steuergeräte hinweg basieren. Dadurch können auch Safetyrelevante CAN-Nachrichten über bestehende Ethernet-Verbindungen des (Fahrzeug)netzwerks übertragen werden, ohne die Safety-Anforderungen der einzelnen Ethernet-Knoten (auch: Hops) zu erhöhen. Da die einzelnen Ethernet-Knoten die Pakete nur weiterleiten und nicht inhaltlich modifizieren, kann der Tunnel zwischen den Endknoten aus Safety-Sicht (auch im Deutschen) als black channel betrachtet werden. Safety-Tags (bspw. CRC) können durch den Senderknoten (durch die erste Recheneinheit des ersten CAN) erstellt und durch den Empfängerknoten (durch die erste Recheneinheit des zweiten CAN) verifiziert werden, während Ethernet-Knoten zwischen Senderknoten und Empfängerknoten an diesem Prozess nicht beteiligt sein müssen.
In dieser Offenbarung wird CAN als CAN etc. (siehe Stand der Technik) verstanden.
Kurzbeschreibung der Figuren

1a illustriert schematisch ein computer-implementiertes Verfahren zum Übertragen von Controller Area Network Frames aus einem ersten Controller Area Network (CAN) in ein zweites Controller Area Network.
1b illustriert schematisch eine Ausführungsform eines computerimplementierten Verfahrens zum Übertragen von Controller Area Network Frames aus einem ersten Controller Area Network (CAN) in ein zweites Controller Area Network.
2a illustriert schematisch ein computer-implementiertes Verfahren zum Empfangen von Controller Area Network Frames aus einem ersten Controller Area Network (CAN) in einem zweiten Controller Area Network.
2b-c illustrieren schematisch Ausführungsformen eines computerimplementierten Verfahrens zum Empfangen von Controller Area Network Frames aus einem ersten Controller Area Network (CAN) in einem zweiten Controller Area Network.
3 illustriert schematisch ein computer-implementiertes Verfahren zum Übertragen von Controller Area Network Frames aus dem ersten Controller Area Network (CAN) in das zweites Controller Area Network und zum Empfangen von Controller Area Network Frames aus dem ersten Controller Area Network (CAN) in dem zweiten Controller Area Network.
4a-b illustrieren jeweils schematisch eine beispielhafte Ausführungsform für ein Computer-System (insbesondere Recheneinheit eines Controller Area Network), das dafür ausgelegt ist, zumindest eines der beschriebenen Verfahren auszuführen.
5a illustriert schematisch ein beispielhaftes erstes CAN-Frame.
5b illustriert schematisch ein beispielhaftes Ethernet-Frame.
5c illustriert schematisch ein beispielhaftes zweites CAN-Frame.

Detaillierte Beschreibung
Die in dieser Offenbarung vorgeschlagenen Verfahren 100, 200, 300 (oder jeweils einer Ausführungsform davon) sind darauf gerichtet, eine sichere Ethernet-basierte Kommunikation zwischen zwei Controller Area Networks (CAN) zu ermöglichen. Die Verfahren sind insbesondere darauf gerichtet, Daten sicher von dem ersten Controller Area Network über das Ethernet in das zweite Controller Area Network zu übertragen.
Im Folgenden kann sich der Begriff CAN auf eine von verschiedenen Versionen von CAN und/oder CAN-inspirierten Weiterentwicklungen (abgekürzt als CAN etc.) beziehen. Controller Area Network kann als CAN abgekürzt werden. Weiterhin kann das Controller Area Network Frame als CAN-Frame abgekürzt werden.
Über diese Kommunikation kann ein technisches System, welches mindestens eines von dem ersten CAN, dem Ethernet, und dem zweiten CAN umfasst, gesteuert, geregelt und/oder überwacht werden. Das technische System kann zum Beispiel ein Fahrzeug sein.
Offenbart wird zunächst ein computer-implementiertes Verfahren 100, z.B. schematisch illustriert in 1a, zum Übertragen von Controller Area Network Frames (d.h. mindestens eines Controller Area Network Frame) aus einem ersten Controller Area Network (CAN) 10 in ein zweites Controller Area Network 20. Das Verfahren 100 kann Empfangen 120, in einer ersten Recheneinheit 11 des ersten Controller Area Network 10, mindestens eines ersten CAN-Frame 13 aus dem ersten Controller Area Network 10 umfassen. Der Schritt 120 kann insoweit entbehrlich sein, als die erste Recheneinheit 11 des ersten Controller Area Network 10 das mindestens eine erste CAN-Frame 13 selbst erzeugen kann und somit nicht mehr empfangen 120 muss. In einem solchen Fall fungiert die erste Recheneinheit 11 selbst als Quellsender.
Das Verfahren 100 umfasst (weiterhin) Transformieren 130 des mindestens einen ersten CAN-Frame 13 in ein Ethernet-Frame 33, wobei Daten 35a zumindest in einem ersten Teil 34a eines Nutzlastfeldes 34 des Ethernet-Frame 33 zumindest Daten 15 eines Nutzlastfeldes 14 des mindestens einen ersten CAN-Frame 13 codieren. Dieses Codieren kann (oder muss) derart sein, dass ausgehend von den Daten 15 hin zu den Daten 35a keine Information verloren geht. CAN-Frames und/oder Ethernet-Frames können zum Beispiel (jeweils) eine Vielzahl von Bitfeldern (d.h. je eines für ein Bit) aufweisen, von denen ein oder mehrere Bitfelder als Nutzlastfeld vorgesehen sind. Ein (erster, zweiter, dritter) Teil 34a, 34b, 34c des Nutzlastfeldes 34 des Ethernet-Frame 33 kann jeweils ein oder mehrere Bitfelder umfassen. Ein Nutzlastfeld kann dafür ausgelegt sein, die zu übertragenden Daten aufzunehmen. Das mindestens eine erste CAN-Frame 13 und das Ethernet-Frame 33 sind schematisch z.B. in 5a bzw. 5b illustriert, wobei die Nicht-Nutzlastfelder nicht dargestellt sind.
Das Verfahren 100 umfasst weiterhin Senden 160, via ein Ethernet 30 und basierend auf einem kryptographischen Netzwerkprotokoll, des Ethernet-Frame 33 an eine erste Recheneinheit 21 des zweiten Controller Area Network 20.
Das Verfahren 100 kann Auswählen des zweiten Controller Area Network 20 unter einer Vielzahl von Controller Area Networks umfassen.
Die erste Recheneinheit 11 des ersten Controller Area Network 10 kann ein Steuergerät sein. Die erste Recheneinheit 11 des ersten CAN 10 kann zum Beispiel ein Zonensteuergerät oder ein Domänen-Gateway sein, wobei die erste Recheneinheit 11 des ersten CAN 10 einer ersten Vertrauenszone in einem Vertrauenszonentrennungskonzept bzw. einer ersten Domäne zugeordnet sein kann.
Die erste Recheneinheit 21 des zweiten Controller Area Network 20 kann ein Steuergerät sein. Die erste Recheneinheit 21 des zweiten CAN 20 kann ebenfalls zum Beispiel ein Zonensteuergerät oder ein Domänen-Gateway sein, wobei die erste Recheneinheit 21 des zweiten CAN 20 einer zweiten Vertrauenszone in dem Vertrauenszonentrennungskonzept bzw. einer zweiten Domäne zugeordnet sein kann.
Eine weitere beispielhafte und im Folgenden beschriebene Ausführungsform des Verfahrens 100 ist schematisch in 1b dargestellt.
Das Ethernet-Frame 33 kann basierend auf einem Übertragungszeitgarantieprotokoll gesendet 160 werden. Das Übertragungszeitgarantieprotokoll kann insbesondere ein Protokoll zur Gewährleistung echtzeitfähiger Kommunikation sein. Das Übertragungszeitgarantieprotokoll, insbesondere das Protokoll zur Gewährleistung echtzeitfähiger Kommunikation, kann zum Beispiel auf einem Time Sensitive Networking (TSN) Standard der IEEE 802.1 Familie basieren oder ein solcher Standard sein. Dadurch können Daten über das Ethernet in (quasi-) Echtzeit übertragen werden. (Quasi-) Echtzeit kann durch mindestens eine Echtzeitanforderung für das technische System definiert sein.
Das Verfahren 100 kann, wie z.B. in 1b dargestellt und z.B. im Sinne von AUTOSAR end-to-end Header, Berechnen 140 gemäß einem vorbestimmten ersten Blockprüfzeichenfolgealgorithmus, einer ersten Blockprüfzeichenfolge 35b, insbesondere einer ersten zyklischen Redundanzprüfinformation, basierend zumindest auf den Daten 15 aus dem Nutzlastfeld 14 des mindestens einen ersten CAN-Frame 13 umfassen. Der vorbestimmte erste Blockprüfzeichenfolgealgorithmus kann insbesondere ein vorbestimmter erster Prüfsummenalgorithmus sein und die erste Blockprüfzeichenfolge 35b kann zum Beispiel eine erste Prüfsumme sein.
Die erste Blockprüfzeichenfolge 35b kann zum Beispiel eine zyklische Redundanzprüfung(sfolge), englisch: cyclic redundancy check (CRC) sein.
Das Verfahren 100 kann sodann Schreiben 141 der ersten Blockprüfzeichenfolge 35b in einen zweiten Teil 34b des Nutzlastfeldes 34 des Ethernet-Frame 33 umfassen. Der zweite Teil 34b des Nutzlastfeldes 34 des Ethernet-Frame 33 ist z.B. schematisch in 5b dargestellt.
Die Schritte 140, 141 können zusammen mit den noch zu beschreibenden Schritten 230, 231 (aus dem Verfahren 200) dazu beitragen, die Sicherheit der zu übertragenden Daten gegen zufällige Änderungen (d.h. die sogenannte safety) zu erhöhen.
Alternativ oder zusätzlich, letzteres wie z.B. in 1b dargestellt, kann das Verfahren 100 Berechnen 150, gemäß einem vorbestimmten ersten Nachrichtenauthentifizierungscodealgorithmus, eines ersten Nachrichtenauthentifizierungscode 35c basierend zumindest auf den Daten 15 aus dem Nutzlastfeld 14 des mindestens einen ersten CAN-Frame 13 sowie auf einem vorbestimmten ersten geheimen Schlüssel 11a umfassen. Der vorbestimmte erste Nachrichtenauthentifizierungscodealgorithmus kann zum Beispiel cipher-based MAC (CMAC) oder hash-based MAC (HMAC) sein.
Das Verfahren 100 kann sodann Schreiben 151 des Nachrichtenauthentifizierungscode 35c in einen dritten Teil 34c des Nutzlastfeldes 34 des Ethernet-Frame 33 umfassen. Der dritte Teil 34c des Nutzlastfeldes 34 des Ethernet-Frame 33 ist ebenfalls schematisch in 5b dargestellt.
Die Schritte 150, 151 können zusammen mit den noch zu beschreibenden Schritten 240, 241 (aus dem Verfahren 200) dazu beitragen, die Sicherheit der zu übertragenden Daten gegen gezielte Manipulationen (d.h. die sogenannte security) zu erhöhen.
Eine Ausführungsform des Verfahrens 100, wie z.B. in 1b dargestellt, mit den Schritten 140, 141, 15, 151 kann dazu beitragen, die Sicherheit der zu übertragenden Daten sowohl gegen zufällige als auch gegen gezielte Manipulationen und somit sowohl die safety als auch die security zu erhöhen.
Anders als in 1b dargestellt, ist die Reihenfolge der Schritte 140 und 150 (falls beide im Verfahren 100 umfasst sind) unerheblich. Der Schritt 140 kann vor, (praktisch) gleichzeitig, oder nach dem Schritt 150 erfolgen.
Ebenso ist die Reihenfolge der Schritte 141 und 151 (falls beide im Verfahren 100 umfasst sind) unerheblich. Der Schritt 141 kann vor, (praktisch) gleichzeitig, oder nach dem Schritt 151 erfolgen.
Die Schritte 140, 141 und/oder 150, 151 können/sollten vor dem Schritt 160 erfolgen.
Die Schritte 140 und/oder 150 können nach Schritt 120 (so vorhanden) erfolgen. Weiterhin kann die Reihenfolge der Schritte 140 und/oder 150 sowie Schritt 130 unerheblich sein.
Das Nutzlastfeld 34 des Ethernet-Frame 33, schematisch illustriert in 5b, kann somit - neben den Daten 15 (dann z.B. 35a) aus dem Nutzlastfeld 14 des ersten CAN-Frame 13 - eine Blockprüfzeichenfolge 35b, insbesondere eine zyklische Redundanzprüfinformation, codieren.
Alternativ oder zusätzlich kann das Nutzlastfeld 34 des Ethernet-Frame 33 - neben den Daten 15 (dann z.B. 35a) aus dem Nutzlastfeld 14 des ersten CAN-Frame 13 - einen Nachrichtenauthentifizierungscode 35c codieren.
Da die Nutzlast eines Ethernet-Frame (typischerweise) größer ist als die Nutzlast eines CAN-Frame muss der Nachrichtenauthentifizierungscode 35c im Ethernet-Frame nicht trunkiert werden. Dagegen kann bisher aufgrund der eingeschränkten Nutzlast bei z.B. High Speed CAN mit AUTOSAR SecOC nur ein trunkierter Nachrichtenauthentifizierungscode in einem CAN-Frame übermittelt werden. Durch Übermitteln untrunkierter Nachrichtenauthentifizierungscodes 35c kann die Sicherheit zumindest im Ethernet erhöht werden.
Das Verfahren 100 kann, wie z.B. optional in 1b dargestellt, Senden 110, via das erste Controller Area Network 10, des mindestens einen ersten CAN-Frame 13 von einer zweiten Recheneinheit 12 des ersten Controller Area Network 10 an die erste Recheneinheit 11 des ersten Controller Area Network 10 umfassen. Das Senden 110 im ersten CAN 10 kann zum Beispiel basierend auf AUTOSAR SecOC abgesichert sein. Dadurch kann die Sicherheit gegen gezielte Änderungen von zu übertragenden Daten auf einem CAN-Bus im ersten CAN 10 erhöht werden.
Weiterhin ermöglicht Schritt 110 zusammen mit dem noch zu beschreibenden Schritt 250 (aus dem Verfahren 200) Daten von dem ersten CAN 10 in das zweite CAN 20 zu übermitteln.
Die zweite Recheneinheit 12 des ersten CAN 10 kann zum Beispiel ein (vakuumunabhängiger, elektromechanischer) Bremskraftverstärker oder eine Fahrdynamikregelungsinstanz in einem Fahrzeug sein. Alternativ oder zusätzlich kann die zweite Recheneinheit 12 des ersten CAN 10 zum Beispiel ein intelligenter Sensor sein.
Offenbart wird weiterhin ein computer-implementiertes Verfahren 200, z.B. schematisch illustriert in 2a, zum Empfangen von Controller Area Network Frames (d.h. mindestens eines Controller Area Network Frame) aus einem ersten Controller Area Network (CAN) 10 in einem zweiten Controller Area Network 20. Das Verfahren 200 umfasst Empfangen 210, in einer ersten Recheneinheit 21 des zweiten Controller Area Network 20 und via ein Ethernet 30 und basierend auf einem kryptographischem Netzwerkprotokoll, eines Ethernet-Frame 33, das von einer ersten Recheneinheit 11 des ersten Controller Area Network 10 gesendet 160 worden ist (d.h. via Verfahren 100), wobei zumindest Daten 35a in einem ersten Teil 34a des Nutzlastfeldes 34 des Ethernet-Frame 33 zumindest Daten 15 des Nutzlastfeldes 14 des mindestens einen ersten CAN-Frame 13 aus dem ersten Controller Area Network 10 codieren.
Das Verfahren 200 umfasst weiterhin Transformieren 220 des Ethernet-Frame 33 in mindestens ein zweites CAN-Frame 23 des zweiten Controller Area Network 20, wobei Daten 25 in einem Nutzlastfeld 24 des mindestens einen zweiten CAN-Frame 23 auf Daten 15 in dem Nutzlastfeld 14 des mindestens einen ersten CAN-Frame 13 basieren. Die Daten 25 in dem Nutzlastfeld 24 des mindestens einen zweiten CAN-Frame 23 können die Daten 15 in dem Nutzlastfeld 14 des mindestens einen ersten CAN-Frame 13 codieren. Dieses Codieren kann (oder muss) derart sein, dass ausgehend von den Daten 15 (oder 35a des Ethernet-Frame 33) hin zu den Daten 25 keine Information verloren geht. Das mindestens eine zweite CAN-Frame 23 ist schematisch z.B. in 5c illustriert, wobei die Nicht-Nutzlastfelder nicht dargestellt sind.
Zum Beispiel können die Daten 25 in dem Nutzlastfeld 24 des mindestens einen zweiten CAN-Frame 23 mit den Daten 15 in dem Nutzlastfeld 14 des mindestens einen ersten CAN-Frame 13 übereinstimmen. Insoweit kann das Transformieren 220 zum Beispiel invers zum Transformieren 130 sein.
Die erste Recheneinheit 11 des ersten Controller Area Network 10 kann ein Steuergerät sein. Die erste Recheneinheit 11 des ersten CAN 10 kann zum Beispiel ein Zonensteuergerät oder ein Domänen-Gateway sein, wobei die erste Recheneinheit 11 des ersten CAN 10 einer ersten Vertrauenszone in einem Vertrauenszonentrennungskonzept bzw. einer ersten Domäne zugeordnet sein kann.
Die erste Recheneinheit 21 des zweiten Controller Area Network 20 kann ein Steuergerät sein. Die erste Recheneinheit 21 des zweiten CAN 20 kann ebenfalls zum Beispiel ein Zonensteuergerät oder ein Domänen-Gateway sein, wobei die erste Recheneinheit 21 des zweiten CAN 20 einer zweiten Vertrauenszone in dem Vertrauenszonentrennungskonzept bzw. einer zweiten Domäne zugeordnet sein kann.
Weitere beispielhafte und im Folgenden beschriebene Ausführungsformen des Verfahrens 200 sind schematisch in 2b-c dargestellt.
Das Ethernet-Frame 33 kann basierend auf einem Übertragungszeitgarantieprotokoll empfangen 210 werden. Das Übertragungszeitgarantieprotokoll kann insbesondere ein Protokoll zur Gewährleistung echtzeitfähiger Kommunikation sein. Das Übertragungszeitgarantieprotokoll, insbesondere das Protokoll zur Gewährleistung echtzeitfähiger Kommunikation, kann zum Beispiel auf einem Time Sensitive Networking (TSN) Standard der IEEE 802.1 Familie basieren oder ein solcher Standard sein. Dadurch können Daten über das Ethernet in (quasi-) Echtzeit übertragen werden. (Quasi-) Echtzeit kann durch mindestens eine Echtzeitanforderung für das technische System definiert sein.
Das Verfahren 200 kann Auslesen einer ersten Blockprüfzeichenfolge 35b aus einem zweiten Teil 34b des Nutzlastfeldes 34 des Ethernet-Frame 33 umfassen. Das Verfahren 200 kann, wie z.B. in 2b-c dargestellt und z.B. im Sinne von AUTOSAR end-to-end Header, Berechnen 230, gemäß einem vorbestimmten zweiten Blockprüfzeichenfolgealgorithmus, einer zweiten Blockprüfzeichenfolge, insbesondere einer zweiten zyklischen Redundanzprüfinformation, basierend zumindest auf Daten 25 aus dem Nutzlastfeld 24 des mindestens einen zweiten CAN-Frame 23 umfassen. Der vorbestimmte zweite Blockprüfzeichenfolgealgorithmus kann insbesondere ein vorbestimmter zweiter Prüfsummenalgorithmus sein und die zweite Blockprüfzeichenfolge kann zum Beispiel eine zweite Prüfsumme sein.
Der vorbestimmte zweite Blockprüfzeichenfolgealgorithmus kann auf dem vorbestimmten ersten Blockprüfzeichenfolgealgorithmus basieren. Zum Beispiel kann der vorbestimmte zweite Blockprüfzeichenfolgealgorithmus der vorbestimmte erste Blockprüfzeichenfolgealgorithmus sein.
Das Verfahren 200 kann sodann erstes Prüfen 231, ob die erste Blockprüfzeichenfolge 35b mit der zweiten Blockprüfzeichenfolge kompatibel ist, insbesondere, ob die erste Blockprüfzeichenfolge 35b mit der zweiten Blockprüfzeichenfolge übereinstimmt, umfassen. Beim ersten Prüfen 231 kann ein erstes Prüfergebnis resultieren. Ob das Senden 250 erfolgt, kann auf dem ersten Prüfergebnis basieren. Zum Beispiel erfolgt das Senden 250, wie z.B. in 2c schematisch dargestellt, unter der notwendigen Bedingung, dass das erste Prüfen 231 erfolgreich (d.h. positiv erstes Prüfergebnis) ist.
Die Schritte 230, 231 können zusammen mit den Schritten 140, 141 (aus dem Verfahren 100) dazu beitragen, die Sicherheit der zu übertragenden Daten gegen zufällige Änderungen (d.h. die sogenannte safety) zu erhöhen.
Alternativ oder zusätzlich, kann das Verfahren 200 Auslesen eines ersten Nachrichtenauthentifizierungscode 35c aus einem dritten Teil 34c des Nutzlastfeldes 34 des Ethernet-Frame 33 umfassen.
Das Verfahren 200 kann, wie z.B. in 2b-c dargestellt, Berechnen 240, gemäß einem vorbestimmten zweiten Nachrichtenauthentifizierungscodealgorithmus, eines zweiten Nachrichtenauthentifizierungscode basierend zumindest auf Daten 25 aus dem Nutzlastfeld 24 des mindestens einen zweiten CAN-Frame 23 sowie auf einem vorbestimmten zweiten geheimen Schlüssel 21a umfassen. Der vorbestimmte erste Nachrichtenauthentifizierungscodealgorithmus kann zum Beispiel cipher-based MAC (CMAC) oder hash-based MAC (HMAC) sein.
Der vorbestimmte zweite Nachrichtenauthentifizierungscodealgorithmus kann auf dem vorbestimmten ersten Nachrichtenauthentifizierungscodealgorithmus basieren. Zum Beispiel kann der vorbestimmte zweite Nachrichtenauthentifizierungscodealgorithmus der vorbestimmte erste Nachrichtenauthentifizierungscodealgorithmus sein.
Das Verfahren 200 kann sodann zweites Prüfen 241, ob der erste Nachrichtenauthentifizierungscode 35c mit dem zweiten Nachrichtenauthentifizierungscode kompatibel ist, insbesondere, ob der erste Nachrichtenauthentifizierungscode 35c mit dem zweiten Nachrichtenauthentifizierungscode übereinstimmt, umfassen. Beim zweiten Prüfen 241 kann ein zweites Prüfergebnis resultieren. Ob das Senden 250 erfolgt, kann (weiterhin) auf dem zweiten Prüfergebnis basieren. Zum Beispiel erfolgt das Senden 250, wie z.B. in 2c schematisch dargestellt, unter der weiteren notwendigen Bedingung, dass das zweite Prüfen 241 erfolgreich (d.h. positiv zweites Prüfergebnis) ist.
Die Schritte 240, 241 können zusammen mit den Schritten 150, 151 (aus dem Verfahren 100) dazu beitragen, die Sicherheit der zu übertragenden Daten gegen gezielte Manipulationen (d.h. die sogenannte security) zu erhöhen.
Eine Ausführungsform des Verfahrens 200, wie z.B. in 2b-c dargestellt, mit den Schritten 230, 231, 240, 241 kann dazu beitragen, die Sicherheit der zu übertragenden Daten sowohl gegen zufällige als auch gegen gezielte Manipulationen und somit sowohl die safety als auch die security zu erhöhen. Die beispielhafte in 2c dargestellt Ausführungsform umfasst alle Schritte 230, 231, 240, 241, wobei das Senden 250 des mindestens einen zweiten CAN-Frame 23 dann erfolgt, wenn sowohl das erste Prüfen 231 als auch das zweite Prüfen 241 erfolgreich ist (d.h. positives erstes Prüfergebnis und positives zweites Prüfergebnis).
Anders als in 2b-c dargestellt, ist die Reihenfolge der Schritte 230 und 240 (falls beide im Verfahren 200 umfasst sind) unerheblich. Der Schritt 230 kann vor, (praktisch) gleichzeitig, oder nach dem Schritt 240 erfolgen.
Ebenso ist die Reihenfolge der Schritte 231 und 241 (falls beide im Verfahren 200 umfasst sind) unerheblich. Der Schritt 231 kann vor, (praktisch) gleichzeitig, oder nach dem Schritt 241 erfolgen.
Die Schritte 230, 231 und/oder 240, 241 können/sollten vor dem Schritt 250 erfolgen.
Die Schritte 230 und/oder 240 können nach Schritt 210 und/oder nach Schritt 220 erfolgen. Weiterhin kann die Reihenfolge der Schritte 230 und/oder 240 sowie Schritt 220 unerheblich sein.
Der vorbestimmte zweite geheime Schlüssel 21a kann mit dem vorbestimmten ersten geheimen Schlüssel 11a korrespondieren. Zum Beispiel kann der vorbestimmte erste geheime Schlüssel 11a und der vorbestimmte zweite geheime Schlüssel 21a ein asymmetrisches Schlüsselpaar bilden. In einem anderen Beispiel kann der vorbestimmte zweite geheime Schlüssel 21a mit dem vorbestimmten ersten geheimen Schlüssel 11a übereinstimmen. In diesem Fall liegt somit ein symmetrischer Schlüssel vor, der von der ersten Recheneinheit 11 des ersten CAN 10 und der ersten Recheneinheit 21 des zweiten CAN 20 geteilt wird.
Das Verfahren 200 kann Senden 250, via das zweite Controller Area Network 20, des mindestens einen zweiten CAN-Frame 23 an eine zweite Recheneinheit 22 des zweiten Controller Area Network 20 umfassen. Das Senden 250 im zweiten CAN 20 kann zum Beispiel basierend auf AUTOSAR SecOC abgesichert sein. Dadurch kann die Sicherheit gegen gezielte Änderungen von zu übertragenden Daten auf einem CAN-Bus im zweiten CAN 20 erhöht werden.
Das Verfahren 200 kann Empfangen 260, via das zweite Controller Area Network 20, des mindestens einen zweiten CAN-Frame 23 in der zweiten Recheneinheit 22 des zweiten Controller Area Network 20 umfassen. Das Empfangen 260 im zweiten CAN 20 kann zum Beispiel basierend auf AUTOSAR SecOC abgesichert sein. Dadurch kann ebenfalls die Sicherheit gegen gezielte Änderungen von zu übertragenden Daten auf einem CAN-Bus im zweiten CAN 20 erhöht werden. Die Schritte 250 und, optional, 260 ermöglichen zusammen mit Schritt 110 (aus dem Verfahren 100) Daten von dem ersten CAN 10 in das zweite CAN 20 zu übermitteln und/oder zu empfangen.
Die zweite Recheneinheit 22 des zweiten CAN 20 kann zum Beispiel ein (vakuumunabhängiger, elektromechanischer) Bremskraftverstärker oder eine Fahrdynamikregelungsinstanz in einem Fahrzeug sein. Alternativ oder zusätzlich kann die zweite Recheneinheit 22 des zweiten CAN 20 zum Beispiel ein intelligenter Sensor sein.
Im Falle, dass die zweite Recheneinheit 12 des ersten CAN 10 und die zweite Recheneinheit 22 des zweiten CAN 20 jeweils Bremskraftverstärker oder Fahrdynamikregelungsinstanzen sind, können, können zum Beispiel das erste CAN 10 in einem vorderen Bereich (insbesondere nahe der Vorderräder) des Fahrzeugs und das zweite CAN 20 in einem hinteren Bereich (insbesondere nahe der Hinterräder) des Fahrzeugs angeordnet sein. Die räumliche Trennung zwischen dem ersten CAN 10 und dem zweiten CAN 20 im Fahrzeug kann durch das Ethernet überbrückt werden.
Offenbart wird weiterhin ein computer-implementiertes Verfahren 300, schematisch z.B. dargestellt in 3, das das computer-implementierte Verfahren 100 zum Übertragen von Controller Area Network Frames aus dem ersten Controller Area Network (CAN) 10 in das zweite Controller Area Network 20 umfasst.
Das Verfahren 300 umfasst weiterhin das computer-implementierte Verfahren 200 zum Empfangen von Controller Area Network Frames aus dem ersten Controller Area Network (CAN) 10 in dem zweiten Controller Area Network 20.
In dem Verfahren 300 ist das Ethernet des Verfahrens 100 das Ethernet des Verfahrens 200. Weiterhin können auch die kryptographischen Netzwerkprotokolle aus den Verfahren 100 und 200 miteinander übereinstimmen. Weiterhin können (oder müssen) auch die Übertragungszeitgarantieprotokolle aus den Verfahren 100 und 200 miteinander übereinstimmen.
Das kryptographische Netzwerkprotokoll im Verfahren 100, 200, 300 kann dafür ausgelegt sein, Authentizität von Daten 35a, 35b, 35c zumindest in dem Nutzlastfeld 34 des Ethernet-Frame 33 sicherzustellen. Alternativ oder zusätzlich kann das kryptographische Netzwerkprotokoll dafür ausgelegt sein, Integrität von Daten 35a, 35b, 35c zumindest im Nutzlastfeld 34 des Ethernet-Frame 33 sicherzustellen. Alternativ oder zusätzlich kann das kryptographische Netzwerkprotokoll dafür ausgelegt sein, Vertraulichkeit von Daten 35a, 35b, 35c zumindest im Nutzlastfeld 34 des Ethernet-Frame 33 sicherzustellen. Zum Beispiel kann das kryptographische Netzwerkprotokoll dafür ausgelegt sein, Authentizität und Integrität, von Daten 35a, 35b, 35c zumindest im Nutzlastfeld 34 des Ethernet-Frame 33, sicherzustellen. In einem anderen Beispiel kann das kryptographische Netzwerkprotokoll dafür ausgelegt sein, Authentizität und Integrität und Vertraulichkeit, von Daten 35a, 35b, 35c zumindest im Nutzlastfeld 34 des Ethernet-Frame 33, sicherzustellen.
Das kryptographische Netzwerkprotokoll ermöglicht somit einen Netzwerk-Tunnel zwischen dem ersten CAN 10 und dem zweiten CAN 20. Eine Absicherung im probabilistischen Sinne kann ausreichend sein.
Das kryptographische Netzwerkprotokoll kann zum Beispiel MACSec sein. Alternativ kann das kryptographische Netzwerkprotokoll z.B. IPSec sein. Alternativ kann das kryptographische Netzwerkprotokoll z.B. TLS sein.
Das Ethernet-Frame 33 kann in den Verfahren 100, 200, 300, wie z.B. in 4b schematisch illustriert, von der ersten Recheneinheit 11 des ersten Controller Area Network 10 über mindestens einen Ethernet-Knoten 31, 32 an die erste Recheneinheit 21 des zweiten Controller Area Network 20 gesendet 160 werden.
Der Ethernet-Knoten 31, 32 kann eine Recheneinheit des Ethernet 30 sein. Der Ethernet-Knoten 31, 32 kann als Hop bezeichnet werden.
Das Ethernet-Frame 33 kann von der ersten Recheneinheit 11 des ersten CAN 10 über eine Vielzahl von Ethernet-Knoten 31, 32 an die erste Recheneinheit 21 des zweiten CAN 20 gesendet 160 werden.
In den Verfahren 100, 200, 300 kann die erste Recheneinheit 11 des ersten Controller Area Network 10 und die erste Recheneinheit 21 des zweiten Controller Area Network 20 in einer Zone mit zu erfüllender erhöhter Sicherheitsanforderung liegen. Dagegen kann der mindestens eine Ethernet-Knoten 31, 32 in einer Zone mit zu erfüllender geringerer Sicherheitsanforderung liegen. Insoweit kann der Netzwerk-Tunnel (auch im Deutschen) als black channel bezeichnet werden.
Die erhöhte Sicherheitsanforderung kann mindestens eine Anforderung von funktionaler Sicherheit umfassen. Die geringere Sicherheitsanforderung kann diese mindestens eine Anforderung der funktionalen Sicherheit nicht umfassen, d.h. die geringere Sicherheitsanforderung muss diese mindestens eine Anforderung der funktionalen Sicherheit nicht umfassen.

Die mindestens eine Anforderung der funktionalen Sicherheit kann auf Absicherung gegen zufällige Änderungen von zu übertragenden Daten 15, 25 gerichtet sein.
Die funktionale Sicherheit kann zum Beispiel gemäß der Norm IEC 61508 definiert sein. Für Fahrzeuge kann insbesondere die funktionale Sicherheit gemäß der Norm ISO 26262 definiert sein.
Durch die erhöhte Sicherheitsanforderung kann somit Integrität im safety-Kontext gewährleistet werden.
Trotz der per se geringeren Sicherheitsanforderungen an das Ethernet kann dank der Verfahren 100, 200, 300 insbesondere ein safety-Nachweis für das Ethernet erbracht werden.
Alternativ oder zusätzlich kann die erhöhte Sicherheitsanforderung mindestens eine Anforderung von Manipulationssicherheit umfassen. Die geringere Sicherheitsanforderung kann dann diese mindestens eine Anforderung der Manipulationssicherheit nicht umfassen, d.h. die geringere Sicherheitsanforderung muss diese mindestens eine Anforderung der Manipulationssicherheit nicht umfassen.
Die mindestens eine Anforderung der Manipulationssicherheit kann auf Absicherung gegen gezielte Änderungen von zu übertragenden Daten 15, 25 gerichtet sein.
Durch die erhöhte Sicherheitsanforderung kann somit Authentizität und Integrität im security-Kontext gewährleistet werden.
In den Verfahren 100, 200, 300 kann der mindestens eine Ethernet-Knoten 31, 32 einen mit dem kryptographischen Netzwerkprotokoll kompatiblen Switch umfassen. Zum Beispiel kann der mindestens eine Ethernet-Knoten 31, 32 einen MACSec-fähigen Switch umfassen. Alternativ oder zusätzlich kann der mindestens eine Ethernet-Knoten 31, 32 eine physische Schnittstelle (englisch: phys) umfassen.
Zum Beispiel kann dadurch die kryptographische Absicherung des Tunnels via MACSec in Line Rate und/oder ohne zusätzliche Latenz an den betroffenen Hops erfolgen.
Die Verfahren 100, 200, 300, insbesondere das Senden 160 des Ethernet-Frame 33 und/oder das Empfangen 210 des Ethernet-Frame 33, können auf unterschiedlichen Ebenen im auf Ethernet aufbauenden Protokollstapel implementiert werden, z.B. auf OSI Layer 4, 3, oder 2. OSI Layer 4 sind beispielsweise die Protokolle TCP und UDP zuzuordnen, OSI Layer 3 das Protokoll IP(v4 oder v6) und Layer 2 Ethernet selbst.
In den Verfahren 100, 200, 300 kann das mindestens eine zweite CAN-Frame 23 dafür verwendet werden, ein technisches System, insbesondere ein Fahrzeug, aus dem ersten Controller Area Network 10 zu steuern, regeln und/oder zu überwachen.
Das technische System, insbesondere das Fahrzeug, kann das erste Controller Area Network 10 umfassen. Alternativ oder zusätzlich kann das technische System, insbesondere das Fahrzeug, das Ethernet 30 umfassen. Alternativ oder zusätzlich kann das technische System, insbesondere das Fahrzeug, das zweite Controller Area Network 20 umfassen. Zum Beispiel kann das technische System, insbesondere das Fahrzeug, das erste Controller Area Network 10, das Ethernet 30 und das zweite Controller Area Network 20 umfassen.
Das erste CAN-Frame 13 kann für eine Funktionalität des technischen Systems, insbesondere des Fahrzeugs, relevant sein. Das erste CAN-Frame 13 kann insbesondere safety-relevant sein. Alternativ oder zusätzlich kann das erste CAN-Frame 13 security-relevant sein. Zum Beispiel kann das erste CAN-Frame 13 safety- und security-relevant sein.
Weiterhin kann das zweite CAN-Frame 23 für eine Funktionalität des technischen Systems, insbesondere des Fahrzeugs, relevant sein. Das zweite CAN-Frame 23 kann insbesondere safety-relevant sein. Alternativ oder zusätzlich kann das zweite CAN-Frame 23 security-relevant sein. Zum Beispiel kann das zweite CAN-Frame 23 safety- und security-relevant sein.
Offenbart wird weiterhin ein Computer-System 400, das dafür ausgelegt ist, das computer-implementierte Verfahren 100 zum Übertragen von Controller Area Network Frames aus einem ersten Controller Area Network (CAN) 10 in ein zweites Controller Area Network 20 auszuführen.
Das Computer-System 400 kann die erste Recheneinheit 11 des ersten Controller Area Network 10 sein oder diese umfassen. Das Computer-System 400 kann einen Prozessor und/oder einen Arbeitsspeicher umfassen. Das Computer-System 400 kann einen nicht-volatilen Speicher umfassen, in dem zum Beispiel der vorbestimmte erste geheime Schlüssel 11a gespeichert ist.
Alternativ oder zusätzlich wird ein Computer-System 400 offenbart, das dafür ausgelegt ist, das computer-implementierte Verfahren 200 zum Empfangen von Controller Area Network Frames aus einem ersten Controller Area Network (CAN) 10 in einem zweiten Controller Area Network 20 auszuführen.
Das Computer-System 400 kann die erste Recheneinheit 21 des zweiten Controller Area Network 20 sein oder diese umfassen. Das Computer-System 400 kann einen Prozessor und/oder einen Arbeitsspeicher umfassen. Das Computer-System 400 kann einen nicht-volatilen Speicher umfassen, in dem zum Beispiel der vorbestimmte zweite geheime Schlüssel 21a gespeichert ist.
Alternativ oder zusätzlich wird ein Computer-System 400 offenbart, das dafür ausgelegt ist, Verfahren 300 auszuführen.
Das Computer-System 400 kann die erste Recheneinheit 11 des ersten Controller Area Network 10 und die erste Recheneinheit 21 des zweiten Controller Area Network 20 umfassen. Das Computer-System 400 kann zwei Prozessoren und/oder zwei Arbeitsspeicher umfassen. Das Computer-System 400 kann zwei nicht-volatile Speicher umfassen, wobei zum Beispiel der vorbestimmte erste geheime Schlüssel 11a in dem einen nicht-volatilen Speicher und der vorbestimmte zweite geheime Schlüssel 21a indem anderen nicht-volatilen Speicher gespeichert ist.
4a-b zeigen beispielhafte Ausführungsformen eines oder mehrerer Computer-Systeme. Im Gegensatz zu 4a zeigt 5b ein Ethernet 30 mit mindestens einem Ethernet-Knoten 31, 32.
Offenbart wird weiterhin ein Computer-Programm, das dafür ausgelegt ist, das Verfahren 100 auszuführen. Alternativ oder zusätzlich wird ein Computer-Programm offenbart, das dafür ausgelegt ist, das Verfahren 200 auszuführen. Alternativ oder zusätzlich wird ein Computer-Programm offenbart, das dafür ausgelegt ist, das Verfahren 300 auszuführen.
Jedes dieser Computer-Programme kann z.B. in interpretierbarer oder in kompilierter Form vorliegen. Es kann (auch in Teilen) zur Ausführung z.B. als Bit- oder Byte-Folge in den RAM eines Computers-Systems 400 geladen werden.
Offenbart wird weiterhin ein computer-lesbares Medium oder Signal, das das Computer-Programm speichert und/oder enthält. Das Medium kann z.B. eines von RAM, ROM, EPROM, HDD, SDD, ... umfassen, auf/in dem das Signal gespeichert wird. Ein Medium, auf dem ein Computer-Programm mit dem Verfahren 100 gespeichert ist, kann der eine nicht-volatile Speicher sein. Ein anderes Medium, auf dem ein Computer-Programm mit dem Verfahren 200 gespeichert ist, kann der andere nicht-volatile Speicher sein.

Claims

Computer-implementiertes Verfahren (100) zum Übertragen von Controller Area Network Frames aus einem ersten Controller Area Network (CAN) (10) in ein zweites Controller Area Network (20), umfassend: - Empfangen (120), in einer ersten Recheneinheit (11) des ersten Controller Area Network (10), mindestens eines ersten CAN-Frame (13) aus dem ersten Controller Area Network (10); - Transformieren (130) des mindestens einen ersten CAN-Frame (13) in ein Ethernet-Frame (33), wobei Daten (35a) zumindest in einem ersten Teil (34a) eines Nutzlastfeldes (34) des Ethernet-Frame (33) zumindest Daten (15) eines Nutzlastfeldes (14) des mindestens einen ersten CAN-Frame (13) codieren; - Senden (160), via ein Ethernet (30) und basierend auf einem kryptographischen Netzwerkprotokoll, des Ethernet-Frame (33) an eine erste Recheneinheit (21) des zweiten Controller Area Network (20).
Verfahren (100) nach Anspruch 1, wobei das Ethernet-Frame (33) basierend auf einem Übertragungszeitgarantieprotokoll, optional basierend auf einem Time Sensitive Networking (TSN) Standard der IEEE 802.1 Familie, gesendet (160) wird.
Verfahren (100) Anspruch 1 oder 2, umfassend: - Berechnen (140), gemäß einem vorbestimmten ersten Blockprüfzeichenfolgealgorithmus, einer ersten Blockprüfzeichenfolge (35b), insbesondere einer ersten zyklischen Redundanzprüfinformation, basierend zumindest auf den Daten (15) aus dem Nutzlastfeld (14) des mindestens einen ersten CAN-Frame (13); - Schreiben (141) der ersten Blockprüfzeichenfolge (35b) in einen zweiten Teil (34b) des Nutzlastfeldes (34) des Ethernet-Frame (33).
Verfahren (100) nach einem der vorhergehenden Ansprüche, umfassend: - Berechnen (150), gemäß einem vorbestimmten ersten Nachrichtenauthentifizierungscodealgorithmus, eines ersten Nachrichtenauthentifizierungscode (35c) basierend zumindest auf den Daten (15) aus dem Nutzlastfeld (14) des mindestens einen ersten CAN-Frame (13) sowie auf einem vorbestimmten ersten geheimen Schlüssel (11a); - Schreiben (151) des Nachrichtenauthentifizierungscode (35c) in einen dritten Teil (34c) des Nutzlastfeldes (34) des Ethernet-Frame (33).
Verfahren (100) nach einem der vorhergehenden Ansprüche, umfassend: - Senden (110), via das erste Controller Area Network 10 und, optional, basierend auf AUTOSAR SecOC, des mindestens einen ersten CAN-Frame (13) von einer zweiten Recheneinheit (12) des ersten Controller Area Network 10 an die erste Recheneinheit (11) des ersten Controller Area Network (10).
Computer-implementiertes Verfahren (200) zum Empfangen von Controller Area Network Frames aus einem ersten Controller Area Network (CAN) (10) in einem zweiten Controller Area Network (20), umfassend: - Empfangen (210), in einer ersten Recheneinheit (21) des zweiten Controller Area Network (20) und via ein Ethernet (30) und basierend auf einem kryptographischem Netzwerkprotokoll, eines Ethernet-Frame (33), das von einer ersten Recheneinheit (11) des ersten Controller Area Network (10) gesendet (160) worden ist, wobei zumindest Daten (35a) in einem ersten Teil (34a) eines Nutzlastfeldes (34) des Ethernet-Frame (33) zumindest Daten (15) eines Nutzlastfeldes (14) des mindestens einen ersten CAN-Frame (13) aus dem ersten Controller Area Network (10) codieren; - Transformieren (220) des Ethernet-Frame (33) in mindestens ein zweites CAN-Frame (23) des zweiten Controller Area Network (20), wobei Daten (25) in einem Nutzlastfeld (24) des mindestens einen zweiten CAN-Frame (23) auf Daten (15) in dem Nutzlastfeld (14) des mindestens einen ersten CAN-Frame (13) basieren.
Verfahren (200) nach Anspruch 6, wobei die Daten (25) in dem Nutzlastfeld (24) des mindestens einen zweiten CAN-Frame (23) mit den Daten (15) in dem Nutzlastfeld (14) des mindestens einen ersten CAN-Frame (13) übereinstimmen.
Verfahren (200) nach Anspruch 6 oder 7, wobei das Ethernet-Frame (33) basierend auf einem Übertragungszeitgarantieprotokoll, optional basierend auf einem Time Sensitive Networking (TSN) Standard der IEEE 802.1 Familie, empfangen (210) wird.
Verfahren (200) nach einem der Ansprüche 6 bis 8, umfassend: - Auslesen einer ersten Blockprüfzeichenfolge (35b) aus einem zweiten Teil (34b) des Nutzlastfeldes (34) des Ethernet-Frame (33); - Berechnen (230), gemäß einem vorbestimmten zweiten Blockprüfzeichenfolgealgorithmus, einer zweiten Blockprüfzeichenfolge, insbesondere einer zweiten zyklischen Redundanzprüfinformation, basierend zumindest auf Daten (25) aus dem Nutzlastfeld (24) des mindestens einen zweiten CAN-Frame (23); - erstes Prüfen (231), ob die erste Blockprüfzeichenfolge (35b) mit der zweiten Blockprüfzeichenfolge kompatibel ist, insbesondere, ob die erste Blockprüfzeichenfolge (35b) mit der zweiten Blockprüfzeichenfolge übereinstimmt.
Verfahren (200) nach einem der Ansprüche 6 bis 9, umfassend: - Auslesen eines ersten Nachrichtenauthentifizierungscode (35c) aus einem dritten Teil (34c) des Nutzlastfeldes (34) des Ethernet-Frame (33); - Berechnen (240), gemäß einem vorbestimmten zweiten Nachrichtenauthentifizierungscodealgorithmus, eines zweiten Nachrichtenauthentifizierungscode basierend zumindest auf Daten (25) aus dem Nutzlastfeld (24) des mindestens einen zweiten CAN-Frame (23) sowie auf einem vorbestimmten zweiten geheimen Schlüssel (21a); - zweites Prüfen (241), ob der erste Nachrichtenauthentifizierungscode (35c) mit dem zweiten Nachrichtenauthentifizierungscode kompatibel ist, insbesondere, ob der erste Nachrichtenauthentifizierungscode (35c) mit dem zweiten Nachrichtenauthentifizierungscode übereinstimmt.
Verfahren (100, 200) nach Anspruch 10, wobei der vorbestimmte zweite geheime Schlüssel (21a) mit dem vorbestimmten ersten geheimen Schlüssel (11a) aus Anspruch 4 korrespondiert; insbesondere, wobei der vorbestimmte zweite geheime Schlüssel (21a) mit dem vorbestimmten ersten geheimen Schlüssel (11a) aus Anspruch 4 übereinstimmt.
Verfahren (200) nach einem der Ansprüche 6 bis 11, umfassend: - Senden (250), via das zweite Controller Area Network (20) und, optional, basierend auf AUTOSAR SecOC, des mindestens einen zweiten CAN-Frame (23) an eine zweite Recheneinheit (22) des zweiten Controller Area Network (20).
Verfahren (200) nach Anspruch 12, umfassend: - Empfangen (260), via das zweite Controller Area Network (20) und, optional, basierend auf AUTOSAR SecOC, des mindestens einen zweiten CAN-Frame (23) in der zweiten Recheneinheit (22) des zweiten Controller Area Network (20).
Computer-implementiertes Verfahren (300), umfassend: - das computer-implementierte Verfahren (100) zum Übertragen von Controller Area Network Frames aus dem ersten Controller Area Network (CAN) (10) in das zweite Controller Area Network (20) nach Anspruch 1 bis 5; - das computer-implementierte Verfahren (200) zum Empfangen von Controller Area Network Frames aus dem ersten Controller Area Network (CAN) (10) in dem zweiten Controller Area Network (20) nach einem der Ansprüche 6 bis 13.
Verfahren (100, 200, 300) nach einem der vorhergehenden Ansprüche, wobei das kryptographische Netzwerkprotokoll dafür ausgelegt ist, Authentizität, Integrität und/oder Vertraulichkeit von Daten (35a, 35b, 35c) zumindest in dem Nutzlastfeld (34) des Ethernet-Frame (33) sicherzustellen.
Verfahren (100, 200, 300) nach einem der vorhergehenden Ansprüche, wobei das kryptographische Netzwerkprotokoll MACSec, IPSec oder TLS ist.
Verfahren (100, 200, 300) nach einem der vorhergehenden Ansprüche, wobei das Ethernet-Frame (33) von der ersten Recheneinheit (11) des ersten Controller Area Network (10) über mindestens einen Ethernet-Knoten (31, 32) an die erste Recheneinheit (21) des zweiten Controller Area Network (20) gesendet (160) wird.
Verfahren (100, 200, 300) nach Anspruch 17, wobei die erste Recheneinheit (11) des ersten Controller Area Network (10) und die erste Recheneinheit (21) des zweiten Controller Area Network (20) in einer Zone mit zu erfüllender erhöhter Sicherheitsanforderung liegen und der mindestens eine Ethernet-Knoten (31, 32) in einer Zone mit zu erfüllender geringerer Sicherheitsanforderung liegt.
Verfahren (100, 200, 300) nach Anspruch 18, wobei die erhöhte Sicherheitsanforderung mindestens eine Anforderung von funktionaler Sicherheit umfasst und die geringere Sicherheitsanforderung diese mindestens eine Anforderung der funktionalen Sicherheit nicht umfasst; optional, wobei die mindestens eine Anforderung der funktionalen Sicherheit auf Absicherung gegen zufällige Änderungen von zu übertragenden Daten (15, 25) gerichtet ist; optional, wobei die funktionale Sicherheit gemäß der Norm IEC 61508 und/oder gemäß der Norm ISO 26262 definiert ist.
Verfahren (100, 200, 300) nach Anspruch 18 oder 19, wobei die erhöhte Sicherheitsanforderung mindestens eine Anforderung von Manipulationssicherheit umfasst und die geringere Sicherheitsanforderung diese mindestens eine Anforderung der Manipulationssicherheit nicht umfasst; optional, wobei die mindestens eine Anforderung der Manipulationssicherheit auf Absicherung gegen gezielte Änderungen von zu übertragenden Daten (15, 25) gerichtet ist.
Verfahren (100, 200, 300) nach einem der Ansprüche 17 bis 20, wobei der mindestens eine Ethernet-Knoten (31, 32) einen mit dem kryptographischen Netzwerkprotokoll kompatiblen Switch, optional einen MACSec-fähigen Switch, und/oder eine physische Schnittstelle umfasst.
Verfahren (100, 200, 300) nach einem der vorhergehenden Ansprüche, wobei das mindestens eine zweite CAN-Frame (23) dafür verwendet wird, ein technisches System, insbesondere ein Fahrzeug, aus dem ersten Controller Area Network (10) zu steuern, regeln und/oder zu überwachen.
Computer-System (400), insbesondere Recheneinheit (11, 21) eines Controller Area Network (10, 20), dafür ausgelegt, das Verfahren (100, 200, 300) nach einem der vorhergehenden Ansprüche auszuführen.
Computer-Programm, dafür ausgelegt, das Verfahren (100, 200, 300) nach einem der Ansprüche 1 bis 22 auszuführen.
Computer-lesbares Medium oder Signal, das das Computer-Programm nach Anspruch 24 speichert und/oder enthält.