DE102014224694B4

DE102014224694B4 - Netzwerkgerät und Netzwerksystem

Info

Publication number: DE102014224694B4
Application number: DE102014224694.6A
Authority: DE
Inventors: c/o Hitachi Ltd. Otsuka Satoshi
Original assignee: Hitachi Astemo Ltd
Current assignee: Hitachi Astemo Ltd
Priority date: 2013-12-12
Filing date: 2014-12-03
Publication date: 2023-01-26
Anticipated expiration: 2034-12-04
Also published as: CN104717201B; CN111447235A; CN111431927A; JP6126980B2; US10542033B2; JP2015114907A; US20200137108A1; DE102014224694A1; US11134100B2; US20150172298A1; US20160344764A1; US9426164B2; CN104717201A

Abstract

Netzwerkgerät, das über einen Bus mit mehreren Netzwerkgeräten verbunden ist, umfassend:
eine Authentifizierungseinheit (501), die eine Authentifizierung auf der Grundlage von Nachrichtenauthentifizierungsinformationen ausführt, die in Daten enthalten sind, welche über den Bus von einem der mehreren Netzwerkgeräte übertragen werden, das als Sendergerät fungiert; und
eine Verarbeitungseinheit (402), die bei fehlgeschlagener Authentifizierung die Daten ungültig macht, wenn bestimmt wird, dass vom Sendergerät, das sich als ein anderes Netzwerkgerät unter den mehreren Netzwerkgeräten ausgibt, nicht autorisierte Daten übermittelt wurden, wobei:
die Daten eine Authentifizierungsergebnisinformation enthalten, die ein Ergebnis der Authentifizierung anzeigen, die von der Authentifizierungseinheit (501) ausgeführt wird; und
wenn die Authentifizierung fehlgeschlagen ist, die Verarbeitungseinheit (402) die Daten ungültig macht, indem ein Wert, der nicht überschrieben werden kann, in die Authentifizierungsergebnisinformation eingesetzt wird.

Description

HINTERGRUND DER ERFINDUNG
1. Gebiet der Erfindung
Die vorliegende Erfindung bezieht sich auf ein Netzwerkgerät und ein Netzwerksystem.
2. Beschreibung verwandter Technik
Die folgende Nicht-Patentliteratur beschreibt Technologien, die den technologischen Hintergrund auf dem Gebiet bilden, das die vorliegende Erfindung betrifft: T. Matsumoto, M. Hata, M. Tanabe, K. Yoshioka, K. Oishi, „A method of preventing unauthorized data transmission in controller area network“, Vehicular Technology Conference (VTC Spring), 2012 IEEE 75. (2012). Diese Veröffentlichung beschreibt folgende Punkte: „Das CAN-Protokoll ist für Busnetzwerke konzipiert. Jede CAN-Nachricht (CAN-Rahmen) hat keine Ausgangs- und auch keine Zieladressen. Deshalb wird jede Nachricht auf einem Bus übertragen. Sobald ein Angreifer in eine ECU eindringt, kann er alle anderen ECUs auf demselben Bus imitieren, weil jede ECU (Knoten), die an einen Bus angeschlossen ist, eine beliebige Nachricht senden kann. Das CAN-Protokoll unterstützt jedoch keine Absenderauthentifizierung und keine Nachrichtenauthentifizierung.“, womit Probleme der CAN-Technologien beschrieben sind. Als Mittel, um diese Probleme zu behandeln, schlägt das Papier „ein Verfahren zum Verhindern einer unautorisierten Datenübertragung durch Unterstützung der Übermittlungseigenschaft des CAN vor. Bei dem vorgeschlagenen Verfahren überwacht die zu imitierende ECU die imitierte Nachricht und erfasst sie, und setzt sie außer Kraft, indem ein Fehlerrahmen (ErrorFrame) gesendet wird, bevor die Nachrichtenübermittlung abgeschlossen ist.“ US 2013/ 0152189 A1 beschreibt eine Authentifizierungsvorrichtung zum Detektieren und Verhindern eines Quelladressen-Spoofing-Pakets, die eine Whitelist-Speichereinheit umfasst, die zum Speichern eines zuverlässigen Quellenknotens konfiguriert ist; eine Blacklist-Speichereinheit umfasst, die zum Speichern eines unzuverlässigen Quellenknotens konfiguriert ist; und eine Paketübertragungseinheit umfasst, die konfiguriert ist, um das Paket, dessen Quelle verifiziert worden ist, zu einem nächsten Netzwerkknoten zu senden. JP 2013 098719 A beschreibt einen Empfangsknoten, der, nachdem er die Hauptnachricht empfangen hat, einen MAC aus dem Datenfeld und der in der Hauptnachricht enthaltenen CAN-ID und dem der CAN-ID entsprechenden Zählerwert erzeugt und ermittelt, ob der MAC mit dem in der MAC-Nachricht enthaltenen MAC übereinstimmt. Auf diese Weise soll überprüft werden, ob die Hauptnachricht gültig ist oder nicht.
US 2007/ 016801 A1 beschreibt ein Datenverarbeitungssystem zum Herstellen von Anmeldeinformationen für die virtuelle Bestätigung, das ein Hardware-Trusted-Platform-Modul (TPM) enthält.
ZUSAMMENFASSUNG DER ERFINDUNG
Die vorstehend angegebene Nicht-Patentliteratur enthält keinerlei Beschreibung von Sicherheitsmaßnahmen für ein Sendernetzwerkgerät. Wenn das Sendernetzwerkgerät angegriffen wird und ausfällt, kann ein Schutz gegenüber dem Angriff nicht gewährleistet werden, da andere Netzwerkgeräte den Angriff nicht so ohne Weiteres feststellen können. Um Netzwerkgeräte vor Angriffen zu schützen, müssen hochentwickelte Sicherheitsmaßnahmen ergriffen werden, wie z. B. das Einführen von Sicherheitsmodulen und eines Verifikationsverfahrens zum Verhindern der Einbeziehung jeglichen verletzbaren Elements. Dies bedeutet, dass bei den einzelnen Sendernetzwerkgeräten wegen solcher Maßnahmen zwangsläufig beträchtliche Kosten entstehen. Ein Netzwerkgerät gemäß der vorliegenden Erfindung, das insbesondere als Gateway GW, elektronische Steuereinheite ECU oder Schalter SW verwirklicht sein kann hat daher die Aufgabe, den Schutz vor Angriffen im Netzwerk zu verbessern.
Gemäß dem ersten Aspekt der vorliegenden Erfindung weist ein Netzwerkgerät, das über einen Bus mit mehreren Netzwerkgeräten verbunden ist, Folgendes auf: eine Authentifizierungseinheit, die eine Authentifizierung auf Grundlage von Nachrichtenauthentifizierungsinformationen durchführt, die in Daten enthalten sind, welche über den Bus von einem der mehreren Netzwerkgeräte übertragen werden, das als Sendergerät fungiert; und/oder eine Verarbeitungseinheit, die bei fehlgeschlagener Authentifizierung die Daten ungültig macht, wenn bestimmt wird, dass vom Sendergerät, das sich als ein anderes Netzwerkgerät unter den mehreren Netzwerkgeräten ausgibt, nicht autorisierte Daten übermittelt wurden, wobei die Daten eine Authentifizierungsergebnisinformation enthalten, die ein Ergebnis der Authentifizierung anzeigen, die von der Authentifizierungseinheit ausgeführt wird, und wenn die Authentifizierung fehlgeschlagen ist, die Verarbeitungseinheit die Daten ungültig macht, indem ein Wert, der nicht überschrieben werden kann, in die Authentifizierungsergebnisinformation eingesetzt wird.
Gemäß dem zweiten Aspekt der vorliegenden Erfindung weist ein Netzwerksystem Folgendes auf: ein Netzwerkgerät gemäß dem ersten Aspekt; und das Sendergerät.
Figurenliste

1 präsentiert ein Beispiel für ein Netzwerksystem, das Netzwerkgeräte umfasst, die in verschiedenen Ausführungsformen der vorliegenden Erfindung verwirklicht sind.
2A, 2B und 2C präsentieren jeweils ein Beispiel für einen inneren Aufbau, der im Netzwerksystem übernommen werden kann.
3 ist eine Abbildung, die ein Aufbaubeispiel für ein Netzwerkgerät präsentiert.
4 stellt ein Beispiel für eine Softwaremodulstruktur dar, die in einem Netzwerkgerät übernommen werden kann.
5A, 5B, 5C und 5D präsentieren jeweils ein Beispiel für eine Datenstruktur, die in Übereinstimmung mit einem speziellen Kommunikationsprotokoll in einem Netzwerk für Daten übernommen werden kann.
6 zeigt eine Tabelle, die angibt, wie eine Datenlängencodierung in Übereinstimmung mit einigen Kommunikationsprotokollen in einem Netzwerk bewerkstelligt werden kann.
7A und 7B präsentieren jeweils ein Beispiel für eine Datenstruktur, die für Daten in Übereinstimmung mit einem Kommunikationsprotokoll in einem Netzwerk übernommen werden kann.
8A und 8B präsentieren jeweils ein Beispiel für eine Datenstruktur, die für Daten in Übereinstimmung mit einem Kommunikationsprotokoll in einem Netzwerk übernommen werden kann.
9 präsentiert ein Beispiel für eine Datenstruktur, die für Daten in Übereinstimmung mit einem Kommunikationsprotokoll in einem Netzwerk übernommen werden kann.
10 präsentiert ein Beispiel für eine Datenstruktur, die für Daten in Übereinstimmung mit einem Kommunikationsprotokoll in einem Netzwerk übernommen werden kann.
11 stellt ein Beispiel für eine Filtertabelle dar.
12A und 12B stellen jeweils ein Beispiel für eine Authentifizierungsprozedur dar.
13 präsentiert ein Beispiel für ein signiertes Kommunikationsdatenformat.
14 stellt ein Beispiel für eine Schlüsselverwaltungstabelle dar.
15 stellt einen Ablaufplan der Verarbeitung dar, die in der Steuereinheit während einer Datenerfassung ausgeführt wird.
16 stellt einen Ablaufplan der Verarbeitung dar, die in der Steuereinheit während einer Datenerfassung in einer zweiten Ausführungsform ausgeführt wird.
17 stellt einen Ablaufplan der Verarbeitung dar, die in der Steuereinheit während einer Datenerfassung in einer vierten Ausführungsform ausgeführt wird.

BESCHREIBUNG VON AUSFÜHRUNGSFORMEN
Es folgt eine Beschreibung von bevorzugten Ausführungsformen der vorliegenden Erfindung. Die Erläuterung legt das Augenmerk auf Betriebsabläufe von Geräten und Systemen in einem Netzwerk wie beispielsweise einem bordeigenen Netzwerk, das in einem mobilen Aufbau, wie etwa einem Fahrzeug, installiert ist, wobei über das Netzwerk Daten übermittelt/empfangen werden. Während die vorliegende Erfindung ideal für Anwendungen in einem bordeigenen Netzwerkgerät und einem Datenübermittlungs-/-empfangssystem in einem bordeigenen Netzwerk ist, kann sie andererseits in einem Netzwerkgerät und einem Netzwerksystem angewendet werden, bei denen es sich nicht um ein bordeigenes Netzwerkgerät bzw. Datenübermittlungs-/-empfangssystem in einem bordeigenen Netzwerk handelt.
(Erste Ausführungsform) < Konfiguration des Netzwerksystems >
1 stellt ein Beispiel eines Netzwerksystems mit Netzwerkgeräten dar, wie es in der ersten Ausführungsform der vorliegenden Erfindung verwirklicht ist. 1 zeigt ein Steuersystem 1, das ein Netzwerksystem 2 umfasst, welches in einem mobilen Aufbau, wie etwa einem Kraftfahrzeug, eingebaut ist. Das Netzwerksystem 2 in 1 ist beispielsweise mit einem bordeigenen Netzwerk (CAN: Controller Area Network, CANFD: CAN mit flexibler Datenrate, Ethernet (eingetragenes Warenzeichen) oder dgl.) konfiguriert. 1 zeigt eine drahtlose Kommunikationseinheit 3, die mit einem Gerät außerhalb des Steuersystems 1 in drahtloser Verbindung steht (z. B. eine Mobiltelefonkommunikation oder eine protokollbasierte Kommunikation wie etwa Wireless LAN oder WAN), und ein Netzwerksystem 4, das ein Protokoll, das sich von dem im Netzwerksystem 2 unterscheidet, oder ein Protokoll verwendet, das mit dem im Netzwerksystem 2 übereinstimmt. 1 zeigt eine drahtgebundene Kommunikationseinheit 5, die zum Beispiel einen Diagnoseanschluss (OBD), einen Ethernet-Anschluss und einen Anschluss für ein externes Aufzeichnungsmedium (zum Beispiel einen USB-Speicher oder eine SD-Karte) aufweist und über eine Drahtverbindung auf das Netzwerksystem 2 zugreift. 1 zeigt eine Ausgabevorrichtung 6, wie beispielsweise eine Flüssigkristallanzeigeeinheit, eine Warnlampe oder einen Lautsprecher, die/der an das Netzwerksystem 2 über eine drahtgebundene oder drahtlose Verbindung angeschlossen ist, einen Datenausgang vom Netzwerksystem 2 empfängt und notwendige Informationen, wie beispielsweise eine Nachrichteninformation (zum Beispiel in Form einer visuellen Anzeige oder eines Tons) anzeigt oder ausgibt. Das Netzwerksystem 2, das mit dem Netzwerksystem 4, der drahtlosen Kommunikationseinheit 3, der drahtgebundenen Kommunikationseinheit 5, der Ausgabevorrichtung 6 und dgl. verbunden ist, tauscht einzeln Informationen mit diesen aus.
2A, 2B und 2C präsentieren jeweils ein Beispiel für einen inneren Aufbaus, der im Netzwerksystem 2 übernommen werden kann. 2A, 2B und 2C zeigen jeweils mehrere Netzwerkverbindungen 301, die einen Bus bilden, der Netzwerkgeräte im Netzwerk verbindet. Bei einer Netzwerkverbindung 301 kann es sich zum Beispiel um eine Netzwerkverbindung in einem CAN-Bus handeln. 2A, 2B und 2C zeigen jeweils ECUs (elektronische Steuereinheiten) 302, die jeweils an eine Netzwerkverbindung 301 und an Hardware wie beispielsweise einen Sensor oder ein Stellglied (nicht gezeigt) oder an eine Netzwerkverbindung (die eine zugehörige Leitung sein kann) angeschlossen sind, die nicht die Netzwerkverbindung 301 ist, wie beispielsweise eine ECU 302, und die mit der Hardwaresteuerung und dem Datenaustausch im Netzwerk befasst ist. 2A, 2B und 2C zeigen jeweils ein Gateway (nachstehend als GW bezeichnet) 303, das die Mehrzahl der Netzwerkverbindungen 301 verbindet und Daten mit den einzelnen Netzwerkverbindungen austauscht.
Das GW 303, das mit einer Mehrzahl von Netzwerkverbindungen 301 verbunden sein kann, weist jeder Verbindung eine Kennung (ID) zu und ist somit in der Lage, eine spezifische Verbindung zu identifizieren, für die gerade eine interne Verarbeitung ausgeführt wird. Die Kennung, die eine solche Identifizierung ermöglicht, wird als Verbindungskennung bezeichnet. Die Verbindungskennung kann anderweitig auch als Kanalkennung oder Domainkennung bezeichnet werden.
2A, 2B und 2C präsentieren Darstellungen von Netzwerktopologien, die voneinander unterschieden werden können. In dem in 2A dargestellten Beispiel sind mehrere ECUs 302 an jeweils zwei Netzwerkverbindungen 301a und 301 b angeschlossen, die einen Bus bilden. Das GW 303 gibt Daten weiter, die zwischen einer an die Netzwerkverbindung 301 a angeschlossenen ECU 302 und einer an die Netzwerkverbindung 301b angeschlossenen ECU 302 übertragen werden.
Das in 2B dargestellte Topologiebeispiel umfasst sowohl eine sternartige Topologie, bei der mehrere ECUs über eine Netzwerkverbindung 301 c, 301 d, ... oder 301 e jeweils direkt mit dem GW 303 verbunden sind, als auch eine busartige Topologie. Der Bus ist mit einer Netzwerkverbindung 301 a und den Netzwerkverbindungen 301 c, 301 d, ... und 301 e konfiguriert. Über zwei Netzwerkverbindungen aus den Netzwerkverbindungen 301 a, 301 c, 301 d, ... und 301 e gibt das GW 303 Daten weiter, die zwischen ECUs 302 übertragen werden.
In dem in 2C dargestellten Beispiel ist ein Schalter (nachstehend als SW bezeichnet) 304 in eine sternartige Topologie eingefügt. Der SW 304 ist mit dem GW 303 über eine Netzwerkverbindung 301f auf der Aufwärtsstreckenseite verbunden. Auf der Abwärtsstreckenseite ist der SW 304 einzeln mit den ECUs 302 über die Netzwerkverbindungen 301g, 301h, ... und 301i verbunden. Der Bus ist mit einer Netzwerkverbindung 301a und den Netzwerkverbindungen 301 f, 301g, 301h, ... und 301i konfiguriert. Über zwei Netzwerkverbindungen unter den Netzwerkverbindungen 301f, 301g, 301h, ... und 301i gibt der SW 304 Daten weiter, die zwischen ECUs 302 übertragen werden. Das GW 303 gibt über die Netzwerkverbindungen 301a und 301f Daten weiter, die zwischen ECUs übertragen werden.
Das GW 303 ist nicht notwendigerweise physisch von einer ECU 302 getrennt. So kann die vorliegende Erfindung zum Beispiel in Verbindung mit ECUs, die eine GW-Funktion haben, oder mit einem GW angewendet werden, das über eine ECU-Funktion verfügt.
In der folgenden Beschreibung der Ausführungsform wird eine Netzwerkprotokollumwandlung seitens des GW 303 ausgeführt, wird aber nicht am SW 304 durchgeführt. Die vorliegende Erfindung kann auch entweder im GW 303 oder im SW 304 angewendet werden.
In der folgenden Beschreibung können Vorrichtungen wie beispielsweise das GW 303, die ECUs 302 und der SW 304, die über Netzwerkverbindungen verbunden sind, anderweitig auch als Netzwerkgeräte bezeichnet werden.
Die Kommunikation wird über die Netzwerkverbindungen 301 in Übereinstimmung mit einem Netzwerkprotokoll (Durchführungsmodus) durchgeführt, das später beschrieben wird. In Übereinstimmung mit dem noch zu beschreibenden Protokoll erfolgt die Kommunikation unter Hinzufügung eines im Protokoll festgelegten Vorspanns zu Daten (nachstehend als Kommunikationsdaten oder Nutzinformation bezeichnet), die zwischen Netzwerkgeräten übermittelt/empfangen werden sollen.
Eine ECU 302 führt eine Steuerungsverarbeitung für einen mobilen Aufbau auf der Grundlage von Daten aus, die über das Netzwerk empfangen werden, um beispielsweise ein Steuersignal an die Hardware auszugeben, ein Steuersignal und die Informationen an das Netzwerk auszugeben und den internen Zustand zu ändern.
3 stellt ein Beispiel für einen inneren Aufbau dar, der im Netzwerkgerät gemäß der vorliegenden Erfindung übernommen werden und als GW 303, ECU 302 oder SW 304 verwirklicht sein kann. 3 zeigt einen Prozessor 401 wie beispielsweise eine CPU, die mit einem Speicherelement, zum Beispiel einem Cachespeicher oder einem Register, ausgestattet ist und die Steuerung ausführt. 3 zeigt auch eine Kommunikationsschnittstelle 402, über die Daten zur Netzwerkverbindung 301 übermittelt oder von dieser empfangen werden. 3 zeigt des Weiteren einen Zeitgeber 403, der mittels eines Taktgebers (nicht gezeigt) oder dgl. Zeitlängen und die aktuelle Zeit verwaltet bzw. bewältigt. Darüber hinaus zeigt 3 einen ROM (Nur-Lese-Speicher) 404, bei dem ein Programm und nichtflüchtige Daten gesichert sind, einen RAM (Direktzugriffsspeicher) 405, in dem flüchtige Daten gesichert sind, und einen internen Bus 406, über den die interne Kommunikation innerhalb der ECU abläuft. 3 zeigt auch ein Sicherheitsmodul 407, das Schlüsselinformationen und dgl. schützt und Vorgänge wie z. B. Authentifizierung, Hash-Operation, Verschlüsselung und Entschlüsselung ausführt.
Die Verwendung des Sicherheitsmoduls 407 ermöglicht es, die Schlüsselinformationen vor einem unerlaubten Zugriff zu schützen und die Verarbeitungslast, wie beispielsweise die Authentifizierung, zu reduzieren. Wenn es jedoch nicht entscheidend ist, einen strengen Manipulationsschutz zu gewährleisten, ist das Sicherheitsmodul 407 nicht vonnöten.
4 zeigt die Konfiguration von Softwaremodulen, die in der CPU 401 in Betrieb stehen. 4 zeigt auch eine Kommunikationsverwaltungseinheit 502, die Betriebsabläufe und den Zustand der Kommunikationsschnittstelle 402 verwaltet und Anweisungen für die Kommunikationsschnittstelle 402 über den internen Bus 406 ausgibt. 4 zeigt darüber hinaus eine Zeitverwaltungseinheit 503, die Zeitlängen betreffende Informationen erhält und eine Zeitlängen betreffende Steuerung durch Verwalten des Zeitgebers 403 ausführt. Zusätzlich zeigt 4 eine Steuereinheit 501, die die Daten analysiert, die über die Kommunikationsschnittstelle 402 erhalten werden, und die Gesamtsteuerung der Softwaremodule ausführt. 4 zeigt auch eine Schlüsselverwaltungstabelle 504 und eine Filtertabelle 505, die beide später beschrieben werden, und einen Pufferspeicher 506, in dem empfangene Daten vorgehalten werden.
4 veranschaulicht das Konzept von Betriebsabläufen, die seitens des Prozessors 401 ausgeführt werden. Jedes Softwaremodul ermöglicht es dem Prozessor 401, vom ROM 404 und RAM 405 Informationen zu erhalten, die für einen bestimmten Vorgang benötigt werden, oder solche Informationen in den ROM 404 und RAM 405 einzuschreiben. Es ist beachten, dass, da die Datenverarbeitung und die Authentifizierungsverarbeitung, die nachfolgend beschrieben werden, möglicherweise mit hoher Geschwindigkeit ausgeführt werden müssen, die Analyse der von der Kommunikationsschnittstelle 402 erhaltenen Daten, die von der Steuereinheit 501 in 4 ausgeführt wird, in Hardware realisiert werden kann.
<Beispiele für Netzwerkprotokolle: CAN und CANFD>
5A, 5B, 5C und 5D stellen Beispiele für Datenstrukturen dar, die in Verbindung mit bestimmten Kommunikationsprotokollen, nach denen eine Kommunikation über die Netzwerkverbindungen 301 ausgeführt wird, übernommen werden können. Für jedes Beispiel ist die Datenstruktur eines Rahmens (auch als Block oder Paket in einer Netzwerkkommunikation bezeichnet) gezeigt, der in Übereinstimmung mit dem CAN- oder CANFD-Protokoll übermittelt/empfangen wird, wobei numerische Werte jeweils die Anzahl von Bits angeben, die einem bestimmten Feld entsprechen.
Gemäß dem CAN- oder CANFD-Protokoll wird eine Kommunikation über Netzwerkgeräte ausgeführt, die an eine gemeinsame Netzwerkverbindung angeschlossen sind, wobei jedes Netzwerkgerät zum Zeitpunkt der Übertragung ein Bussignal auf den dominanten Wert (0) setzt und jedes Netzwerkgerät zum Zeitpunkt der Übermittlung oder des Empfangs das Bussignal dahingehend erfasst, dass es entweder im dominanten Zustand (0) oder rezessiven Zustand (1) ist.
Ein SOF (Start Of Frame = Rahmenbeginn) gibt die Startposition des Rahmens an. Es wird auch für die Rahmensynchronisation verwendet.
In einem Kennungsfeld (ID-Feld) ist die ID bzw. die Kennung der bestimmten CAN-Daten (nachstehend als CAN-ID bezeichnet) angegeben. Die Datenart der CAN-Daten kann auf der Grundlage der CAN-ID bestimmt werden.
Das ID-Feld und ein RTR- (Remote Transmission Request = Fernübermittlungsaufforderung) Bit werden als Arbitrierungsfeld bezeichnet, und dieses Feld wird zur Busarbitrierung verwendet.
Bei einem RB1 und einem RB0 handelt es sich um reservierte Bits, bei denen in dem in 5A dargestellten Beispiel der dominante Wert durchgängig eingeben ist. Wenn im RBO jedoch der rezessive Wert angegeben ist, wird von einem erweiterten Format, wie beispielweise von dem in 5B gezeigten, ausgegangen, wodurch es möglich ist, dass die ID mit 29 Bits ausgedrückt wird. Die Struktur, die in dem erweiterten Format für das Datenfeld und darüber hinaus übernommen wird, ist mit der in 5A gezeigten identisch.
Ein Datenlängencode gibt die Länge (Anzahl von Bytes) der Daten in einem Datenfeld an.
Die Inhalte der zu übertragenden Daten sind im Datenfeld angegeben. Daten, die äquivalent zu N Bytes sind, werden unter Annahme einer variablen Länge übermittelt. Das Datenfeld kann auch als Nutzinformation bezeichnet werden.
CRC-Ergebnisse für den Rahmen werden in ein CRC-Feld eingegeben. Wenn der Rahmen übermittelt wird, wird der rezessive Wert in einem CRC-Begrenzer aufrechterhalten, der an ein Bestätigungsfeld angrenzt.
Wenn ein Empfängerknoten (Netzwerkgerät) die Daten erfolgreich empfangen hat, wird als Reaktion darauf das Bestätigungsbit im Bestätigungsfeld auf den dominanten Wert gesetzt. Somit wird eine Antwort zurückgeschickt, die sich darauf bezieht, dass Daten übermittelt wurden.
Ein EOF (end of frame = Rahmenende), welches das Abschlussende des Rahmens anzeigt, ist ein rezessives Feld mit 7 Bits. Daten werden übermittelt und empfangen, indem das vorstehend beschriebene Format übernommen wird.
Verschiedene Arten der Steuerung werden für ein Fahrzeug über ein bordeigenes Netzwerk ausgeführt, das mit der Verarbeitung befasst ist, wobei zum Beispiel ein bestimmtes Netzwerkgerät regelmäßig einen Wert (z. B. einen Sensorwert), der auf messtechnischem Weg von dem bestimmten Netzwerkgerät erhalten wurde, an das Netzwerk übermittelt und ein durch den Wert angegebener Zustand einem anderen Netzwerkgerät gemeldet wird.
In einem CAN wird eine Arbitrierung im Arbitrierungsfeld durchgeführt, wenn Daten übermittelt werden. Wenn gleichzeitig Datenübermittlungen beginnen, hält ein Netzwerkgerät mit einer niedrigeren Priorität (mit einer größeren CAN-ID (d. h. das Netzwerkgerät, das eine geringere Anzahl an dominanten Werten während der Arbitrierung übermittelt hat)) die Übertragung zurück. Das bedeutet, dass, selbst wenn einzelne Netzwerkgeräte versuchen, Daten zyklisch zu übermitteln, ein vorübergehender Aufschub stattfinden kann, und zwar als Ergebnis der Arbitrierung oder infolgedessen, dass ein anderes Netzwerkgerät möglicherweise bereits Daten übermittelt, wenn eine Datenübermittlung beginnt. In einem solchen Fall können die Übermittlungszyklen versetzt werden. Dieses Phänomen, bei dem mehrere Netzwerkgeräte versuchen, Daten mit zeitlicher Überlappung zu übertragen, oder bei dem der Bus bereits in Verwendung ist, wenn ein Netzwerkgerät eine Datenübermittlung versucht, wird als Kollision bezeichnet.
Als Nächstes wird das CANFD-Protokoll erläutert. Da es sich bei CANFD um ein Protokoll handelt, das eine erweiterte Version des CAN ist, beschäftigt sich die folgende Erläuterung in erster Linie mit dem Unterschied zum CAN. 5C zeigt die Datenstruktur, die im standardmäßigen CANFD-Format übernommen wird.
Ein EDL ist ein Bit, das anzeigt, dass das CANFD-Format übernommen ist. Und zwar zeigt ein auf den rezessiven Wert gesetztes EDL an, dass die Übermittlungsdaten das CANFD-Format annehmen, und ein auf den dominanten Wert gesetztes EDL zeigt an, dass die Übermittlungsdaten das CAN-Format annehmen.
BRS zeigt an, ob die Bitrate während der Datenübermittlung umgestellt werden soll oder nicht. Ist BRS auf den rezessiven Wert gesetzt, zeigt dies an, dass die Bitrate während der Datenphase umzustellen ist, während ein auf den dominanten Wert gesetztes BRS angibt, dass die Bitrate nicht umzuschalten ist.
ESI gibt einen Fehlerstatus des Netzwerkgeräts an, das Daten übertragen soll. Das auf den dominanten Wert gesetzte ESI zeigt an, dass das zur Übertragung von Daten vorgesehene Netzwerkgerät in einem aktiven Fehlerzustand ist, wohingegen das auf den rezessiven Wert gesetzte ESI anzeigt, dass das Netzwerkgerät zur Übertragung von Daten in einem passiven Fehlerzustand ist.
Im Datenlängencodefeld unterscheidet sich des Weiteren das für die Datenlängencodierung verwendete Verfahren im CANFD-Protokoll vom dem im CAN-Protokoll. 6 zeigt Datenlängencodierverfahren. Im CAN-Protokoll handelt es sich bei Bit 0, Bit 1 und Bit 2 in Daten mit einer Datenlänge von 8 Bytes um bedeutungslose Bits. Wie die Tabelle in 6 angibt, erlaubt das CANFD-Protokoll, dass Daten mit bis zu 64 Bytes ausgedrückt werden.
Das CRC-Feld im CANFD-Protokoll nimmt eine variable Länge an. Mit anderen Worten nimmt die Feldlänge, die sich entsprechend der Datenlänge verändert, eine Feldlänge mit 17 Bits oder eine Feldlänge mit 21 Bits ein. Zusätzlich sind im CANFD-Protokoll im CRC-Begrenzerfeld und im Bestätigungsfeld 2 Bits an Daten untergebracht.
Bei RB1 und RBO handelt es sich um reservierte Bits, wobei in dem in 5C dargestellten Beispiel der dominante Wert dauerhaft eingegeben ist. Im CANFD-Protokoll wird, wenn der rezessive Wert in einem IDE angegeben ist, ein erweitertes Format, wie beispielsweise das in 5D gezeigte, übernommen, und die ID kann somit mit 29 Bits ausgedrückt werden. Die Struktur, die in dem erweiterten Format für das Datenfeld und darüber hinaus übernommen wurde, ist mit der in 5C gezeigten identisch.
Das Arbitrierungsfeld und das Steuerfeld im CAN-Protokoll können andererseits auch als Vorspann bezeichnet werden.
Das CRC-Feld ist enthalten, um eine Verifikation bezüglich dessen zu ermöglichen, ob ein Signal irgendeinen Fehler enthält oder nicht. Wenn vom Empfänger empfangene Daten mit dem vom Absender übermittelten Inhalt und mit dem Inhalt übereinstimmen, der sich aus einer seitens des Absenders durchgeführten CRC-Operation ergibt, werden über eine empfängerseitig ausgeführte CRC-Operation dieselben Ergebnisse angezeigt. Diese Maßnahmen gestatten es dem Empfänger, den Empfang von Daten abzulehnen (die Daten zu verwerfen), wenn die empfangenen Daten nicht mit den Übermittlungsdaten übereinstimmen, die der Absender zu senden beabsichtigte (im Falle eines CRC-Fehlers).
<Beispiel eines Netzwerkprotokolls: Ethernet>
7A und 7B zeigen Datenstrukturen (Rahmenstrukturen), die in Verbindung mit dem Ethernet-Protokoll übernommen werden können. 7A zeigt eine Struktur, die das DIX-Format.übernimmt, während 7B eine Struktur zeigt, die das Format IEEE 802.3 übernimmt.
In einem Präambelfeld und einem Feld SFD (Start Frame Delimiter = Startrahmenbegrenzer) werden Daten unter Annahme eines festgelegten Schemas eingegeben, das dazu verwendet wird, eine Kommunikationssynchronisierung zu erlangen. In einem Zieladressenfeld ist die Adresse des Datenübermittlungsziels angegeben, wohingegen in einem Ausgangsadressenfeld die Adresse der Datenübermittlungsquelle angegeben ist. In einem Typusfeld wird ein Wert eingegeben, der die Protokollart einer höher angesiedelten Ebene angibt, wobei die Länge die Länge des Datenfelds (Oktett: in 8-Bit-Einheiten) angibt, während die Nutzinformation der Daten in ein Datenfeld eingegeben wird. FCS (Rahmenprüfsequenz) ist ein Feld zur Rahmenfehlererfassung, in dem Operationsergebnisse ähnlich den zuvor erläuterten CRC-Operationsergebnissen enthalten sind. Die numerischen Werte in den Figuren geben jeweils die Länge (in Oktett-Einheiten) des entsprechenden Feldes an.
<Beispiele für Netzwerkprotokolle: IP/TCP/UDP>
Das IP (Internetprotokoll) stellt ein Beispiel für ein Protokoll einer höher angesiedelten Ebene bezüglich der Ethernet- und CAN-Protokolle dar. In 8A und 8B sind Datenstrukturen gezeigt, die für Daten in Übereinstimmung mit dem Internetprotokoll übernommen werden können. Für den IP-Vorspann werden verschiedene Strukturen übernommen, die jeweils einer bestimmten Version entsprechen. 8A zeigt die Vorspannstruktur, die der Version 4 (IPv4) entspricht, wohingegen 8B die Vorspannstruktur zeigt, die der Version 6 (IPv6) entspricht. Obwohl die IP-Vorspannbereiche entsprechend den beiden Versionen unterschiedliche Längen haben, enthält die Vorspanninformation in jeder Version die Ausgangsadresseninformation und Zieladresseninformation, um eine Identifizierung des Absenders und des Empfängers zu ermöglichen. Die Kommunikationsdaten sind in der Nutzinformation enthalten.
Übergeordnete Protokolle bezüglich des IP-Protokolls umfassen das TCP-Protokoll und das UDP-Protokoll. 9 zeigt ein Beispiel für eine TCP-Vorspannstruktur, während 10 ein Beispiel für eine UDP-Vorspannstruktur darstellt. Die Vorspanninformation in den TCP/UDP-Ebenenprotokollen enthält weder Absenderinformationen noch Empfängerinformationen, gibt aber die verwendeten Ports an (Zahlen, die eine Ermittlung von Kommunikationsarten ermöglichen).
Innerhalb der schichtweisen Struktur, die mit der Mehrzahl der vorstehend beschriebenen Protokolle aufgebaut ist, kann die Kommunikation zum Beispiel unter Verwendung der TCP/IP/Ethernet-Protokolle durchgeführt werden. Unter solchen Umständen werden den zu übermittelnden Kommunikationsdaten der TCP-Vorspann, der IP-Vorspann und der Ethernet-Vorspann angehängt, und alle diese Daten werden je nach Bedarf vereinigt oder aufgeteilt, bevor sie übermittelt werden.
Durch Nachvollziehen der schichtweisen Struktur können die exakten Positionen in den empfangenen Daten, an denen die den Absender identifizierenden Informationen und die den Inhalt der Kommunikation identifizierenden Informationen eingefügt sind, sowie die Position der Daten, die für eine Authentifizierung notwendig sind, genau ermittelt werden.
<Formatfehler>
Die vorstehend beschriebenen Protokolle umfassen Felder mit bestimmten Bits, die einen vorbestimmten Wert oder einen Wert innerhalb eines vorbestimmten Bereichs angeben. Ein solches bestimmtes Bit kann zum Beispiel ein reserviertes Bit sein. Jedes Ereignis, bei dem irgendeines dieser Bits einen Wert angibt, der sich von dem in dem bestimmten Format definierten unterscheidet, wird als Formatfehler bezeichnet.
Zusätzlich wird im CAN-Protokoll eine Bitauffüllregel übernommen, wonach ein anderer Wert übernommen wird, wenn ein gegebener Wert über fünf aufeinanderfolgende Bits unverändert blieb, so dass während einer normaler Kommunikation nicht derselbe Wert fortlaufend für sechs oder mehr Bits verwendet werden kann. Auch eine Verletzung dieser Auffüllregel wird als Formatfehler bezeichnet.
Darüber hinaus wird als Formatfehler auch die Erscheinung eines Schemas bezeichnet, das ein anderes ist als ein vorbestimmtes Schema (z. B. werden serielle elektrische Potentialwerte vier Mal in einer Zeile eingegeben), was dem Modulationsverfahren, das in der physikalischen Schicht übernommen ist, oder dem Codierverfahren zugeschrieben werden kann, das in der Datenverbindungsschicht verwendet wird.
<Daten, die überschrieben werden können, und Daten, die nicht überschrieben werden können>
Wenn Daten in Übereinstimmung mit einem der vorstehend beschriebenen Protokolle übermittelt werden, übermittelt der Absender jedes Signal durch Steuerung des Pegels (1,0) des elektrischen Potentials oder durch Steuerung des Pegels der elektrischen Potentialdifferenz zwischen verdrillten Zweidrahtleitungen, und der Empfänger empfängt Signale, indem er unter ähnlicher Steuerung eine Entscheidung trifft. Bei einer solchen Datenübermittlung kann sich ein dominanter Signalstatus zeigen, wie er in der physikalischen Schicht des Protokolls definiert ist.
Im CAN-Protokoll ist im dominanten Zustand (0) das elektrische Potential zum Beispiel auf 0 gesetzt oder die Potentialdifferenz ist auf 0 gesetzt, und wenn eines der an eine Verbindung angeschlossenen Netzwerkgeräte eine Signalleitung hiervon auf Masse zieht, können die anderen Netzwerkgeräte den rezessiven Wert (1) nicht ausgeben. Aus diesem Grund können Daten, die den rezessiven Wert angeben, überschrieben werden, während Daten, die den dominanten Wert angeben, nicht überschrieben werden können.
Im Ethernet-Protokoll, das eine andere Struktur für die physikalische Schicht übernimmt, kann das übermittelte elektrische Potential auf einen überschreibbaren Wert oder einen nicht überschreibbaren Wert gesetzt werden, indem ebenfalls eine Signalleitung auf Masse gezogen wird, um so ein Überschreiben von Daten zu ermöglichen oder zu verweigern.
<Filtertabelle>
11 stellt ein Beispiel für die Filtertabelle 505 dar. Für jeden Datensatz liefert die Filtertabelle in 11 eine Datenkennung 1201, die zur Identifizierung der über einen Bus übertragenen Daten verwendet wird, eine Senderverbindungskennung 1202, die einer Netzwerkverbindung 301 zugewiesen ist, an welche die Datensender-ECU 302 angeschlossen ist, eine Empfängerverbindungskennung 1203, die einer Netzwerkverbindung 301 zugewiesen ist, mit der die Datenempfänger-ECU 302 verbunden ist, ein Senderprotokoll 1204, welches das Datenkommunikationsprotokoll angibt, das aufseiten der Sender-ECU 302 verwendet wird, ein Empfängerprotokoll 1205, das das Datenkommunikationsprotokoll angibt, das in der Netzwerkverbindung 301 verwendet wird, mit der die Datenempfänger-ECU 302 verbunden ist, und einen Authentifizierungszielmerker 1206, der angibt, ob es sich bei den bestimmten Daten um ein Authentifizierungsziel handelt oder nicht.
Die Filtertabelle 505 ist eine Verwaltungstabelle, die dazu verwendet wird, zu bestimmen, ob eine Datenübertragung über den Bus gestattet ist oder nicht, und zwar auf der Grundlage dessen, ob die Zieldaten eine Übereinstimmung in den Datenkennungen 1201 haben oder nicht. Die Filtertabellen 505 sind auch im GW 303 und SW 304 installiert, wo eine Datenübertragungsverarbeitung ausgeführt wird, um Daten mit einer passenden Datenkennung 1201 von einer Netzwerkverbindung 301, d.h. der Aufwärtsstrecke, zu einer anderen Netzwerkverbindung 301, d.h. der Abwärtsstrecke, zu übertragen. Die im GW 303 und SW 304 installierten Filtertabellen 505 fungieren jeweils als eine Weiterleitungstabelle, die auf der Grundlage der Senderverbindungskennung 1202 und der Empfängerverbindungskennung 1203 eine bestimmte Aufwärtsstrecke, über die Daten ankommen, die mit einer bestimmten Datenkennung 1201 übereinstimmen, und eine bestimmte Abwärtsstrecke angibt, über die die Daten abgehen. Die im GW 303 und SW 304 installierten Filtertabellen 505 fungieren jeweils auch als Protokollumwandlungstabelle, die auf der Grundlage des Senderprotokolls 1204 und des Empfängerprotokolls 1205 angibt, ob eine Protokollumwandlung auszuführen ist oder nicht, wenn die über die Aufwärtsstrecke angekommenen Daten wieder durch die Abwärtsstrecke abgehen.
Beispiele für eine Daten-ID 1201 umfassen CAN-IDs im CAN-Protokoll und im CANFD-Protokoll, MAC-Adressen im Ethernet-Protokoll, IP-Adressen im IP-Protokoll, eine Portnummer im TCP-Protokoll oder im UDP-Protokoll sowie eine Kombination verschiedener oben aufgeführter Arten von Informationen. So können zum Beispiel auf der Grundlage der Portnummer in Kombination mit der Ausgangs- und Ziel-IP-Adresse die Kommunikationsstrecke und der in Anspruch genommene Dienst identifiziert werden.
Der Authentifizierungszielmerker 1206 gibt an, ob für die über den Bus übertragenen Daten eine Authentifizierungsverarbeitung auszuführen ist oder nicht, die später noch beschrieben wird. „Ja“ gibt an, dass für die Daten eine Authentifizierung auszuführen ist, während „Nein“ angibt, dass die Daten keine Authentifizierungsverarbeitung durchlaufen müssen. Wenn Daten, die alle Datenkennungen enthalten, Authentifizierungsziele sind oder nur Daten, die in die Schlüsselverwaltungstabelle 504 (wird später noch beschrieben) eingetragen sind, als Authentifizierungsziele bezeichnet werden, ist der Authentifizierungszielmerker 1206 nicht erforderlich.
Das GW 303 mit einer darin installierten Filtertabelle 505 erfasst auf der Grundlage der Filtertabelle 505, dass zwischen ECUs 302, die an eine gemeinsame Netzwerkverbindung 301 angeschlossen sind, über den Bus Daten übertragen werden, oder erfasst die Übertragung von Daten über zwei Netzwerkverbindungen 301. Das GW 303 greift auf das Senderprotokoll 1204 und das Empfängerprotokoll 1205 zu, die in der Filtertabelle 505 registriert sind, und führt eine Datenprotokollumwandlung je nach Bedarf während der Datenübertragungsverarbeitung aus. Eine ECU 302 mit einer darin installierten Filtertabelle 505 nimmt nicht an der Datenübertragungsverarbeitung von einer Netzwerkverbindung 301 auf eine andere Netzwerkverbindung 301 teil. Das heißt, dass, solange das Protokoll eingestellt ist, das in der einzelnen Netzwerkverbindung 301 an die die bestimmte ECU 302 angeschlossen ist, verwendet wird, die Filtertabelle 505 keine Information zu enthalten braucht, die die Senderverbindungskennungen 1202, Empfängerverbindungskennungen 1203, Senderprotokolle 1204 und Empfängerprotokolle 1205 angibt. Wenn der SW 304 keine Protokollumwandlung ausführt, wenn Daten von einer Netzwerkverbindung 301 auf eine andere Netzwerkverbindung 301 übertragen werden, und ein vorbestimmtes eingeschränktes Protokoll in den mehreren Netzwerkverbindungen 301 verwendet wird, an die der SW 304 angeschlossen ist (zum Beispiel wird in den mehreren Netzwerkverbindungen nur das Ethernet-Protokoll verwendet), braucht die Filtertabelle 505 im SW 304 keine Informationen zu enthalten, die Senderprotokolle 1204 und Empfängerprotokolle 1205 angeben.
<Datenerfassungsverarbeitung, Übertragungsverarbeitung und Datenverarbeitung, die in der Kommunikationsschnittstelle ausgeführt werden>
Um eine Datenerfassungsverarbeitung über die Kommunikationsschnittstelle 402 zu ermöglichen, liest der Prozessor 401 Filterinformationen, die in Übereinstimmung mit Datenkennungen eingeschrieben sind, die während der Konstruktionsphase zugewiesen wurden, um zum Beispiel Daten anzugeben, die einer Übertragung bedürfen, aus der Filtertabelle 505 aus und setzt die so ausgelesenen Filterinformationen in die Kommunikationsschnittstelle 402 ein. Die Kommunikationsschnittstelle 402 mit den darin eingestellten, spezifische Datenkennungen angebenden Filterinformationen überwacht Signale, die von Sender-ECUs 302 zu Empfänger-ECUS 302 über Netzwerkverbindungen 301 übertragen werden. Wenn auf den Netzwerkverbindungen 301 Daten übertragen werden, die eine Datenkennung enthalten, die mit einer Datenkennung übereinstimmt, die als Authentifizierungsziel spezifiziert ist, übergibt die Kommunikationsschnittstelle 402 die Daten zusammen mit der Datenkennung an den Prozessor 401, um den Prozessor 401 in die Lage zu versetzen, die Authentifizierungsverarbeitung durchzuführen. Wenn die Authentifizierung in der Kommunikationsschnittstelle 402 ausgeführt werden soll, brauchen die Daten und die Datenkennung nicht unbedingt dem Prozessor 401 übergeben zu werden.
Während der Datenerfassungsverarbeitung kann die Kommunikationsschnittstelle 402 eine Datenkennung eintragen, die eine andere ist als die in der Filtertabelle 505 gespeicherten Datenkennungen, wie vorstehend anhand eines Beispiels erläutert, indem die neue Datenkennung zur Filtertabelle 505 hinzugefügt wird. Die Kommunikationsschnittstelle 402 kann zum Beispiel eine CAN-ID im CAN-Protokoll oder eine Ethernet-Adresse mit einer Maskenspezifikation (die ermöglicht, dass für ein bestimmtes Bit ein beliebiger Wert empfangen werden kann) in die Filtertabelle 505 eintragen, um in der Lage zu sein, Daten zu ermitteln, die einer Datenkennung innerhalb eines bestimmten Bereichs entsprechen, oder sie kann alle Bits in einer CAN-ID oder einer Ethernet-Adresse maskieren, um so alle Daten erfassen zu können.
In Ansprechung auf eine vom Prozessor 401 ausgegebene Datenübertragungs-Verarbeitungsanweisung, die zusammen mit Übertragungszielinformationen über die Kommunikationsschnittstelle 402, die im GW 303 oder SW 304 befindlich ist, das bzw. der an der Datenübertragungsverarbeitung für Daten beteiligt ist, die von der Aufwärtsstrecke zur Abwärtsstrecke übertragen werden, werden über eine Netzwerkverbindung 301 Daten ausgegeben, die erhalten werden, indem nötige Informationen an die Übertragungszielinformationen angehängt werden, und die ein Datenformat annehmen, das dem Netzwerkprotokoll entspricht.
Zudem verarbeitet die Kommunikationsschnittstelle 402 die spezifizierten Daten, und sie erfasst und überträgt die spezifizierten Daten auch. Wenn zum Beispiel der aktuelle Wert eines Signals auf einer Netzwerkverbindung 301 in digitaler Darstellung 0 ist (z.B. wenn das elektrische Potential auf der bestimmten Netzwerkverbindung 301 niedriger als ein Referenzwert ist), führt die Kommunikationsschnittstelle 402 eine Operation zum Umschreiben des Signalwerts auf 1 in digitaler Darstellung aus (was z.B. anzeigt, dass das elektrische Potential auf der Netzwerkverbindung 301 höher als der Referenzwert ist). Sie führt auch einen umgekehrten Vorgang des Überschreibens des aktuellen Signalwerts eines Signals auf der Netzwerkverbindung 301 von 1 auf 0 in digitaler Darstellung aus. Diese Vorgänge werden auch ausgeführt, wenn eine Kommunikationsantwort zurückkehrt (z.B. eine Ack (Bestätigung)).
<Vortäuschung>
Als Nächstes werden mit Bezug auf 2A, 2B und 2C Beispiele für Vortäuschung bzw. Spoofing beschrieben, deren Verhinderung eine Hauptaufgabe der vorliegenden Erfindung ist. Ein Angreifer kann eine ECU 302 (nachstehend als ECU_A bezeichnet) angreifen, die an ein externes Kommunikationsgerät angeschlossen ist, kann Daten im ROM 404 oder RAM 405 innerhalb der ECU in unerlaubter oder nicht autorisierter Weise überschreiben (manipulieren), und die ECU_A dazu verwenden, der Netzwerkverbindung 301 über die ECU_A unautorisierte, gefälschte Daten zu übermitteln, die sich als andere ECU ausgibt (nachstehend als ECU_B bezeichnet). Unter solchen Umständen kann die andere ECU, die die gefälschten Daten empfangen hat, möglicherweise eine fehlerhafte Entscheidung in Bezug auf den aktuellen Zustand treffen, was zu einem fehlerhaften Vorgang führt. Diese Form eines Angriffs wird als Vortäuschungsangriff bezeichnet.
Die Datenmanipulation seitens der ECU_A ist nicht die einzige beispielhafte Möglichkeit eines Vortäuschungsangriffs. Ein Vortäuschungsangriff kann auch anderweitig ausgeführt werden, indem ein unzulässiges Gerät direkt an die Netzwerkverbindung 301 angeschlossen wird oder indem es sich als ein Gerät ausgibt, das an die ECU angeschlossen ist, um falsche Informationen zu übermitteln.
<Authentifizierungsverarbeitung>
Ein Vortäuschungsangriff kann durch eine Authentifizierung von Daten (einer Nachricht) verhindert werden. Der Begriff „Authentifizierung“ bezieht sich auf eine Technologie, bei der der Absender eine Signatur (elektronische Signatur) erzeugt, indem geheim gehaltene Informationen (nachstehend als Schlüssel oder Schlüsselinformationen bezeichnet) verwendet werden und der Empfänger bestätigt, dass die Daten vom richtigen Absender gesendet wurden, indem er die Signatur verifiziert.
Die Daten können zum Beispiel als durch den richtigen Absender übermittelte, nicht manipulierte Daten verifiziert werden, indem eine Signatur (MAC: Message Authentication Code, Nachrichtenauthentifizierungscode) als Nachrichtenauthentifizierungsinformation authentifiziert wird. In 12A und 12B sind Vorgehensweisen gezeigt, durch die diese Authentifizierung erfolgen kann.
12A stellt ein Beispiel für einen Vorgang dar, der ausgeführt wird, indem ein herkömmliches Schlüsselverfahren übernommen wird, d.h. die Absenderseite und die Empfängerseite dieselben Schlüsselinformationen gemeinsam nutzen. Der Absender führt einen Vorgang aus, um den Hash für die zu übermittelnden Daten zu bestimmen. Der Ausdruck „Hash“ wird dazu verwendet, um auf Informationen zu verweisen, die die Eigenschaften der Daten repräsentieren. Der im Hash angegebene Wert ändert sich stark, wenn die Daten manipuliert wurden, und aus diesem Grund werden die Informationen verwendet, um zu bestätigen, dass die Daten nicht verfälscht wurden.
Als Nächstes wird der Hash verschlüsselt (codiert). Zum Zwecke der Verschlüsselung werden der im Besitz des Absenders befindliche Schlüssel (Absenderschlüssel) und begleitende Informationen verwendet. Dann wird zusammen mit den Daten eine Signatur übermittelt, die erzeugt wird, indem der Hash mit dem Absenderschlüssel verschlüsselt wird.
Der Ausdruck „begleitende Informationen“ wird dazu verwendet, um auf Informationen zu verweisen, die separat vom Schlüssel verwendet werden, um zum Beispiel zu verhindern, dass ein systematischer Fehler in der Signatur entsteht. Für diese begleitenden Informationen kann ein Initialisierungsvektor (IV) verwendet werden. Die begleitenden Informationen enthalten Informationen, die vorab durch einen noch zu beschreibenden Schlüsselaustauschvorgang oder dgl. übertragen oder an die Signaturdaten angehängt werden, um von der Absenderseite und der Empfängerseite gemeinsam genutzt zu werden. Die begleitenden Informationen können zusammen mit den Daten verschlüsselt werden oder können unverschlüsselt bleiben.
Auf der Empfängerseite wird für die empfangenen Daten eine Signatur erzeugt, und zwar über eine Vorgehensweise, die identisch zu derjenigen ist, die auf der Senderseite verfolgt wurde. Dabei wird unter Verwendung eines empfängerseitigen Schlüssels, der identisch zu dem vom Absender verwendeten Schlüssel ist, eine identische Verarbeitung ausgeführt, so dass identische Signaturdaten erhalten werden.
Wenn die Daten oder die Signatur verfälscht (manipuliert) wurde(n), stimmen die beiden Signaturen nicht überein. Somit ist es möglich zu verifizieren, ob die Zieldaten manipuliert wurden oder nicht, wodurch es letztendlich ermöglicht wird zu verifizieren, ob eine Vortäuschung seitens des Absenders stattgefunden hat oder nicht.
Als eine Alternative zur vorstehend beschriebenen Vorgehensweise können eine Hash-Operation und eine Verschlüsselung gleichzeitig ausgeführt werden (HMAC: Hash-Based MAC = auf Hash basierender MAC). In diesem Fall kann der Absenderschlüssel zum Beispiel zu den Daten, die der Hash-Operation unterzogen werden, hinzugefügt werden (XOR), um so eine Signatur zu erzeugen. Daraufhin wird eine gleichartige Operation auf der Empfängerseite ausgeführt, um eine Signatur zu erzeugen, und die Authentifizierung kann durch Vergleichen der Signaturen erzielt werden. Wenn die Signaturen übereinstimmen, wird eine Authentifizierungs-OK-Entscheidung getroffen, wohingegen, wenn die Signaturen nicht übereinstimmen, eine Authentifizierungs-NG-Entscheidung gefällt wird.
Während die Vorgänge in den zuvor beschriebenen Beispielen unter Anwendung eines Verfahrens mit gemeinsamem Schlüssel ausgeführt werden, bei dem sich die Absenderseite und die Empfängerseite dieselben Schlüsselinformationen teilen, kann die vorliegende Erfindung für eine Verarbeitung übernommen werden, bei der kein gemeinsamer Schlüssel (symmetrischer Schlüssel) erforderlich ist und die wie in 12B gezeigt ausgeführt wird. In diesem Beispiel erfolgt auf der Absenderseite eine ähnliche Prozedur wie die vorstehend beschriebene, wobei aber der Empfänger, anstatt eine gleichartige Vorgehensweise zu befolgen, den Daten-Hash-Wert durch Entschlüsselung der Signatur ermittelt und den so ermittelten Hash-Wert mit einem Hash-Wert vergleicht, der auf der Grundlage der Daten separat berechnet wurde, um so die an die Daten angehängte Signatur zu verifizieren. Wenn die Hash-Werte übereinstimmen, wird eine Authentifizierungs-OK-Entscheidung getroffen, wohingegen, wenn die Hash-Werte nicht übereinstimmen, eine Authentifizierungs-NG-Entscheidung erfolgt. Dieses Verfahren ermöglicht die Verifizierung der Signatur selbst dann, wenn die Schlüssel nicht zueinander symmetrisch sind, und macht eine parallele Ausführung der Hash-Operationsverarbeitung und der Entschlüsselungsverarbeitung möglich.
Eine Authentifizierung, die der in 12B gezeigten Authentifizierung ähnlich ist, kann auch in Verbindung mit einem gemeinsamen Schlüssel ausgeführt werden.
Da die Verarbeitungslast eines Vorgangs mit asymmetrischem Schlüssel normalerweise hoch ist, ist es schwierig, ein Reaktionsverhalten oder ein Echtzeitverhalten zu gewährleisten. Aus diesem Grund sollte durch die noch zu beschreibende Schlüsselaustauschprozedur vorab ein gemeinsamer Schlüssel geteilt werden.
Die Datenoperation wird ausgeführt, indem neben den für die Kommunikation erforderlichen Daten verschiedene Arten von Daten an die Daten angehängt werden. So kann zum Beispiel ein Zeitstempel (Zeitpunktinformation, die beispielsweise den Zeitpunkt der Übermittlung angibt) an die Daten angehängt werden, wobei in diesem Fall ein Wiederholungsangriff durch einen Nachahmer, der unter Vorgabe eines autorisierten Absenders dieselben Daten erneut sendet, verhindert werden kann. Zusätzlich kann eine Zufallszahl angehängt werden, um jedes Mal verschiedene verschlüsselte Daten zu erzeugen. In diesem Fall wird es schwierig sein, die Schlüsselinformationen zu erraten. Darüber hinaus ist es auf der Grundlage eines an die Daten angehängten Zählers möglich zu verifizieren, dass Daten in der richtigen Abfolge (zeitlicher Ablauf) übermittelt wurden.
Für die Hash-Operation braucht keine bestimmte Verarbeitung ausgeführt zu werden. Wenn keine Hash-Operationsverarbeitung ausgeführt wird, sinkt die Betriebslast, obwohl kein hoher Grad an Informationsvermischung erzielt werden kann.
Signiertes Kommunikationsdatenformat>
13 zeigt ein Format von signierten Kommunikationsdaten. Dieses Datenformat bezieht sich auf die Daten in der Nutzinformation gemäß den vorstehend beschriebenen Netzwerkprotokollen.
13 zeigt ein Feld 1401 signiert/unsigniert, in dem Informationen enthalten sind, die angeben, ob eine Signatur angehängt ist oder nicht, ein Kommunikationsdatenlängenfeld 1402, in dem Informationen enthalten sind, die die Länge der Kommunikationsdaten angeben, ein Signaturlängenfeld 1403, in dem Informationen enthalten sind, die die Länge der Signatur angeben, ein Kommunikationsdatenfeld 1404, ein Signaturdatenfeld 1405, das Signaturdaten enthält, die auf der Absenderseite durch die zuvor erläuterte Authentifizierungsverarbeitung erzeugt wurden, ein Spielraumfeld 1406, das dazu verwendet wird, einen zeitlichen Spielraum zu enthalten, der gegebenenfalls benötigt wird, bis die Authentifizierungsverarbeitungsoperation abgeschlossen ist, und ein Authentifizierungs-Ack-Feld 1407, in dem Authentifizierungsergebnisinformationen enthalten sind, die dazu verwendet werden zu bestimmen, ob eine Authentifizierung auf normalem Wege ausgeführt worden ist oder nicht.
Signierte Kommunikationsdaten müssen nicht unbedingt alle Informationen enthalten, die den vorstehend aufgeführten Feldern entsprechen. In einem höher angesiedelten Protokoll können die Informationen im Feld signiert/unsigniert zum Beispiel im Vorspann enthalten sein. Genauer ausgedrückt, können die Informationen im Feld signiert/unsigniert in dem Typusfeld im Ethernet-Vorspann oder Protokollfeld im IP-Vorspannprotokoll als signaturbasiertes Protokoll definiert sein. Im CAN-Protokoll oder CANFD-Protokoll kann ein reserviertes Bit verwendet werden, um anzuzeigen, ob die Authentifizierung erforderlich ist oder nicht. Als Alternative können spezifische Kombinationen von Absendern, Empfängers und einschlägigen Diensten, die bei einer Übermittlung von signierten Kommunikationsdaten heranzuziehen sind, vorab bestimmt werden. Durch diese Maßnahmen erübrigt sich die Notwendigkeit des Feldes signiert/unsigniert. Da sie es vor dem Empfang der Nutzinformation ermöglichen zu bestimmen, ob die Authentifizierung erforderlich ist oder nicht, wird eine schnellere Verarbeitung erzielt (die Information, die angibt, ob eine Authentifizierung erforderlich ist oder nicht, wird mit relativ raschem Timing empfangen, und es kann bestimmt werden, dass für bestimmte Nutzinformationen keine Entscheidungsfindung erforderlich ist). Zusätzlich ermöglichen sie die Koexistenz mit Altgeräten (weil Daten, die einen nicht authentifizierten Vorspann entsprechend einem unkorrekten Protokoll in sich tragen, von den Altgeräten automatisch verworfen werden).
Darüber hinaus ist es nicht notwendig, dass jeder Satz von Übertragungsdaten in unveränderlicher Weise Informationen enthält, die die Kommunikationsdatenlänge und Signaturlänge angeben. So kann zum Beispiel die Notwendigkeit, dass die Informationen die Kommunikationsdatenlänge und die Signaturlänge angeben, aus der Welt geschafft werden, indem vorab feststehende Werte für die Kommunikationsdatenlänge und die Signaturlänge bestimmt werden, bevor die signaturbasierte Kommunikation tatsächlich stattfindet, und indem die Kommunikation mit den bestimmten, feststehenden Werten erfolgt. In diesem Fall kann das übermittelte Datenvolumen reduziert werden.
Das Spielraumfeld 1406 und das Authentifizierungs-Ack-Feld 1407 sind nicht erforderlich, es sei denn, ihre Felder werden wegen eines noch zu beschreibenden Gebrauchs verwendet.
Des Weiteren müssen die Signaturdaten nicht unbedingt in allen übermittelten Daten enthalten sein; stattdessen kann für jede Kommunikationseinheit in einer höheren Ebene eine Signatur erzeugt werden. Wenn zum Beispiel ursprüngliche Daten mit 1 MB auf mehrere Pakete aufgeteilt werden, braucht nur das letzte Paket eine Signatur zu enthalten. Durch diese Maßnahmen ist es möglich, den Umfang arithmetischer Operationen zu reduzieren, die auf der Absender- und Empfängerseite ausgeführt werden müssen.
<Schlüsselaustauschprozedur>
Für eine erfolgreiche Authentifizierungsverarbeitung muss das Schlüsselmanagement sowohl auf der Absenderseite als auch auf der Empfängerseite sichergestellt sein. Insbesondere die Verwendung desselben Schlüssels kontinuierlich über einen langen Zeitraum ist mit einer Erhöhung des Sicherheitsrisikos verbunden, da mit erhöhter Wahrscheinlichkeit ein Schlüsselinformationsleck auftritt. Aus diesem Grund ist es wünschenswert, einen temporären Schlüssel (Sitzungsschlüssel) mit jedem spezifischen Intervall zu aktualisieren, anstatt kontinuierlich denselben Schlüssel zu benutzen.
Dementsprechend tauschen zum Beispiel zwei ECUs 302 Schlüsselinformationen über eine Schlüsselaustauschverarbeitung aus. Bei der Schlüsselaustauschverarbeitung kann eine ECU 302 einen Sitzungsschlüssel mit einem von der anderen ECU 302 bereitgestellten, öffentlichen Schlüssel verschlüsseln und den verschlüsselten Sitzungsschlüssel an die andere ECU 302 weitergeben. Die andere ECU 302, die den verschlüsselten Sitzungsschlüssel empfangen hat, kann dann den Sitzungsschlüssel erhalten, indem sie den verschlüsselten Sitzungsschlüssel mit ihrem eigenen privaten Schlüssel entschlüsselt. Der Sitzungsschlüssel, der wie zuvor beschrieben ausgetauscht wurde, wird dann als Absenderschlüssel und Empfängerschlüssel bei der Authentifizierungsverarbeitung benutzt.
In einem anderen Beispiel einer Schlüsselaustauschverarbeitung wird das Schlüsselpaar, d.h. der öffentliche Schlüssel und der private Schlüssel, nicht verwendet. Stattdessen wird ein inhärenter Schlüssel (Hauptschlüssel) im ROM 404 oder im Sicherheitsmodul 407 in jeder ECU 302 zum Zeitpunkt der Herstellung oder bei einer Wartung eingebettet, und die Hauptschlüsselinformation wird zum Zeitpunkt der Herstellung oder bei der Wartung mit jeder ECU 302 ausgetauscht, mit der die bestimmte ECU 302 in Kommunikation treten soll. Wenn das Produkt verwendet wird, wird gemeinsam ein Sitzungsschlüssel benutzt, der unter Verwendung der individuellen Hauptschlüssel verschlüsselt wurde.
Durch jedes dieser Verfahren können die Schlüsselinformation oder verschiedene Arten von Informationen, die sich auf die Schlüsselinformation beziehen (wie z. B. der Gültigkeitszeitraum für den Schlüssel, der Initialisierungsvektor, die Verschlüsselungszieldatenkennung und dgl.) sicher austauscht werden. Es ist zu beachten, dass, während die Erläuterung unter Bezugnahme auf ECUs 302 erfolgte, die vorstehend beschriebenen Konzepte jeweils auch auf das GW 303 oder den SW 304 angewendet werden können.
<Schlüsselverwaltungstabelle>
14 stellt ein Beispiel für die Schlüsselverwaltungstabelle dar. Die Schlüsselverwaltungstabelle 504 stellt die folgenden Informationen bereit: eine Datenkennung 1501, die eine Feststellung der bestimmten Authentifizierungszieldaten ermöglicht, ein Protokoll 1502, gemäß dem die Authentifizierungszieldaten übermittelt werden, Schlüsseldaten 1503, die zur Authentifizierung verwendet werden, einen Gültigkeitszeitraum 1504 für die Schlüsseldaten, ein Merker 1505, der angibt, ob der Schlüssel gültig ist oder nicht, eine Datenlänge 1506 von Kommunikationsdaten 1404 und eine Signaturlänge 1507. Die Schlüsselverwaltungstabelle 504 verwaltet Schlüssel, die bei der Authentifizierung von Authentifizierungszieldaten von der Steuereinheit 501 zu verwenden sind.
Die Datenkennungen 1501 sind den Datenkennungen 1201 in der Filtertabelle 505 ähnlich. Auf der Grundlage der Informationen in einer Datenkennung 1501, die die Kommunikationsstrecke angeben, des in Anspruch genommenen Diensts und dgl., die sich auf einen bestimmten, der Datenkennung 1501 entsprechenden Datensatz beziehen, kann der Schlüssel entsprechend der bestimmten Datenkennung 1501 bestimmt werden.
Da zusätzlich das Protokoll 1502 angegeben ist, können die spezifischen Positionen ermittelt werden, an denen die Kommunikationsdaten und die Signatur in den empfangenen Daten enthalten sind. Dem Protokoll 1502 entsprechende Informationen sind auch in der Filtertabelle 505 enthalten, wovbei ein Beispiel in 11 präsentiert ist. Solange die Protokollinformationen 1502 entweder in der Schlüsselverwaltungstabelle 504 oder in der Filtertabelle 505 enthalten sind, kann man auf sie entsprechend der Datenkennung 501 oder Datenkennung 1201 zugreifen.
Bei den Schlüsseldaten 1503 kann es sich um den unmittelbaren Datenwert der Schlüsselinformationen, eine den Schlüssel identifizierende Schlüsselkennung oder einen den Schlüssel angebenden Zeiger handeln. Wenn es sich bei den Schlüsseldaten 1503 um die Schlüsselkennung handelt, können die Daten dem Sicherheitsmodul 407 übermittelt werden, damit die Signatur durch Spezifizierung der Schlüsselkennung verifiziert wird. Diese Maßnahmen gewährleisten eine hochsichere Verwaltung der Schlüsseldaten, ohne dabei Gefahr zu laufen, dass sich ein Schlüsseldatenleck ergibt, und machen es auch möglich, die Authentifizierung auszuführen, ohne den Prozessor einer übermäßigen Belastung auszusetzen.
In dem Feld für den Schlüsselgültigkeitszeitraum 1504 ist der Gültigkeitszeitraum für den bestimmten Schlüssel eingegeben. Jedes Mal, wenn der Schlüssel aktualisiert wird, wird bei Bedarf auch der Gültigkeitszeitraum aktualisiert. Bestimmte Schlüssel können unbegrenzt gültig sein. Wenn kein Schlüssel erhalten wurde, kann eine Information eingegeben werden, die angibt, dass ein Schlüssel noch zu besorgen ist (zum Beispiel eine Information, die die absolute vergangene Zeit angibt: beispielsweise ALLO). Durch diese Maßnahmen erübrigt sich die Notwendigkeit des noch zu beschreibenden Schlüsselinformations-Gültigkeitsmerkers 1505.
Der Schlüsselinformations-Gültigkeitsmerker 1505 gibt an, ob die entsprechende Schlüsselinformation gültig ist oder nicht. Ein ungültiger Zustand eines Schlüssels kann sich dann zeigen, wenn zum Beispiel die der spezifischen Datenkennung entsprechenden Schlüsselinformationen nicht mit dem Sendernetzwerkgerät ausgetauscht wurden, oder wenn die Schlüsselinformationen aufgrund eines unerlaubten Zugriffs oder eines Angriffs ungültig gemacht wurden.
Die Kommunikationsdatenlänge 1506 und die Signaturlänge 1507 bieten Informationen, wie sie bei der Kommunikationsdatenlänge 1402 und der Signaturlänge 1405 im signierten Kommunikationsdatenformat bereitgestellt werden. Mit den in der Schlüsselverwaltungstabelle 504 enthaltenen Informationen bezüglich der Kommunikationsdatenlänge 1506 und der Signaturlänge 1507 braucht die Verarbeitung zum Erlangen der Kommunikationsdatenlänge 1402 und der Signaturlänge 1405 im signierten Kommunikationsdatenformat nicht jedes Mal ausgeführt zu werden, wenn eine Kommunikation durchgeführt wird, so dass die Rechenlast erleichtert werden kann.
<Verarbeitung, die ausgeführt wird, wenn Daten erfasst werden, die von der Sender-ECU zur Empfänger-ECU über den Bus übertragen werden>
Mit Bezug auf 15 wird die Verarbeitung beschrieben, die von der Steuereinheit 501 im Prozessor 401 eines Netzwerkgeräts (einer ECU 302, eines GW 303 oder eines SW 304) ausgeführt wird, wenn Daten über den Bus von einer Sender-ECU, die gerade mit einer bestimmten Art von Steuerung für das Fahrzeug beschäftigt ist, auf eine Empfänger-ECU übertragen werden, die gleichermaßen mit einer bestimmten Art von Steuerung für das Fahrzeug beschäftigt ist. Während die folgende Erläuterung unter der Annahme erfolgt, dass die vorliegende Erfindung in einem GW 303 angewendet wird, kann eine ähnliche Verarbeitung in einer ECU 302 oder einem SW 304 ausgeführt werden, für die bzw. den die vorliegende Erfindung übernommen wird.
Zunächst erfasst die Kommunikationsschnittstelle 402 im GW 303 Authentifizierungszieldaten aus allen Daten, die über den Bus durch die Netzwerkverbindungen 301 übertragen werden, und zwar auf der Grundlage der durch den Prozessor 401eingestellten Filterinformationen. Anschließend greift die Steuereinheit 501, die von der Kommunikationsschnittstelle 402 über die Authentifizierungszieldatenerfassung in Kenntnis gesetzt wurde, auf die Filtertabelle 505 und die Schlüsselverwaltungstabelle 504 zu, um eine Entscheidung dahingehend zu treffen, ob die Datenkennung der übertragenen Daten mit einer Datenkennung in diesen Tabellen übereinstimmt oder nicht, wobei der entsprechende Authentifizierungszielmerker auf „Ja“ gesetzt wird (Schritt S101). Es ist zu beachten, dass, da die Kommunikationsschnittstelle 402 die Authentifizierungszieldaten auf der Grundlage der vom Prozessor 401 eingestellten Filterinformationen erfasst, es in Schritt S101 nicht unbedingt notwendig ist, auf die Filtertabelle 505 oder die Datenkennungen in der Schlüsselverwaltungstabelle 504 zuzugreifen. In Schritt S101 wird für Daten, deren Datenkennung keinerlei Entsprechung in den Tabellen findet, oder für Daten, bei denen der Authentifizierungszielmerker auf „Nein“ gesetzt ist, eine negative Entscheidung gefällt. Wenn in Schritt S101 eine negative Entscheidung getroffen wird, wird die Datenauthentifizierungsverarbeitung in Schritt S102 nicht ausgeführt. Eine affirmative Entscheidung erfolgt in Schritt S101 für Daten, deren Datenkennung mit einer Datenkennung in den Tabellen übereinstimmt und deren Authentifizierungszielmerker auf „Ja“ gesetzt ist. Die Steuereinheit 501 greift auf die Schlüsselverwaltungstabelle 504 zu und führt die Datenauthentifizierungsverarbeitung (Schritt S102) auf der Grundlage des Schlüssels durch, der den Authentifizierungszieldaten entspricht, für die in Schritt S101 eine affirmative Entscheidung getroffen wurde. Wie vorstehend erläutert, wird die Authentifizierungsverarbeitung ausgeführt, um zu bestimmen, ob die Daten von einer Fremdeinheit übertragen werden, die sich als Sender-ECU 302 ausgibt.
Wenn die Authentifizierungsergebnisse ein OK anzeigen (erfolgreiche Authentifizierung), wird daraufhin in Schritt S103 eine affirmative Entscheidung getroffen. In diesem Fall übergibt die Steuereinheit 501 die authentifizierten Daten an die Kommunikationsschnittstelle 402 ohne Ausführung irgendwelcher besonderen Verarbeitung der Daten. Seitens der Empfänger-ECU 302, welche die übergebenen Daten empfangen hat, werden aus den übertragenen Daten unverschlüsselte, in 13 gezeigte Kommunikationsdaten 1404 extrahiert. Wenn die Authentifizierungsergebnisse für Daten, die unter Vortäuschung übertragen wurden, NG anzeigen, erfolgt in Schritt S103 eine negative Entscheidung. Unter diesen Umständen beurteilt die Steuereinheit 501 die übertragenen Daten als nicht autorisierte Daten, die unter Vortäuschung der Sender-ECU 302 übertragen wurden, und wenn sie die Daten an die Kommunikationsschnittstelle 402 übergibt, erteilt sie der Kommunikationsschnittstelle 402 eine Anweisung, die Daten so zu verarbeiten, dass sie beispielsweise ungültig gemacht werden, wie nachfolgend beschrieben wird (Schritt S104).
Wie vorstehend beschrieben, kann eine Übertragung von nicht autorisierten Daten durch Vortäuschung des Sendergeräts verhindert werden, indem die Datenauthentifizierungsergebnisse verifiziert werden und die Daten beispielsweise so verarbeitet werden, dass sie ungültig gemacht werden, wenn die Authentifizierungsergebnisse NG anzeigen. Es ist zu beachten, dass die Authentifizierungsverarbeitung, die, wie vorstehend in Bezug auf 15 beschrieben ist, durch die Steuereinheit 501 ausgeführt wird, stattdessen aufseiten der Kommunikationsschnittstelle 402 ausgeführt werden kann. Indem man die Authentifizierungsverarbeitung auf die Kommunikationsschnittstelle 402 überträgt, wird bei der Verarbeitung eine höhere Geschwindigkeit erzielt. Darüber hinaus kann die Datenverarbeitung, die in Schritt S104 in 15 seitens der Kommunikationsschnittstelle 402 als Reaktion auf eine von der Steuereinheit 501 erteilte Anweisung ausgeführt wird, stattdessen auch durch die Steuereinheit 501 ausgeführt werden. Wenn die vorliegende Erfindung in der Vorrichtung angewendet wird, die Daten weitergibt, die über zwei Netzwerkverbindungen 301 übertragen werden, wie etwa das GW 303 oder der SW 304, ist es wünschenswert, dass die Steuereinheit 501 an einem bestimmten, noch zu beschreibenden Teil der Datenverarbeitung beteiligt ist, was als Verarbeitung auf höherer Ebene bezeichnet wird, wodurch sich zum Beispiel der Authentifizierungs-Ack-Wert verändert, im Gegensatz zur Verarbeitung auf einer niedrigeren Ebene wie beispielsweise die Fehlerrahmenerzeugung.
<Datenannullierung>
Die mit der Datenverarbeitung befasste Kommunikationsschnittstelle 402 macht Daten ungültig, indem sie sie so verarbeitet, dass die Empfänger-ECU 302, die die übertragenen Daten empfängt, in die Lage versetzt wird, einen Fehlschlag der Authentifizierung zu erfassen. Daten können zum Beispiel im CAN-Protokoll oder CANFD-Protokoll ungültig gemacht werden, indem der dominante Wert kontinuierlich über 6 Bits oder mehr im übertragenen Rahmen erzeugt wird, um den bestimmten Rahmen zu einem Fehlerrahmen zu machen. Durch diese Maßnahmen können die übertragenen Daten ungültig gemacht werden.
Als Alternative kann die Authentifizierung Ack 1407, die die Authentifizierungsergebnisinformation im signierten Kommunikationsdatenformat trägt und ursprünglich vom Absender auf den rezessiven Wert gesetzt wurde, auf den dominanten Wert umgestellt werden, um ein Überschreiben nicht zu gestatten. Das Empfängernetzwerkgerät ist nach Überprüfung des Authentifizierung Ack, das den dominanten Wert anzeigt, in der Lage zu verifizieren, dass die Daten aufgrund einer fehlgeschlagenen Authentifizierung für ungültig erklärt wurden.
Darüber hinaus werden mit Änderung der Authentifizierungs-Ack-Daten die CRC-Operationsergebnisse unrichtig gemacht, womit die Daten, die nun als fehlerhaltige Daten angesehen werden, gleichermaßen ungültig gemacht werden können
Als weitere Alternative kann der dominante Wert (elektrisches Potential 0) als feststehender Wert verwendet werden, um eine Kommunikation über eine vorbestimmte Zeitdauer zu sperren. In diesem Fall können die Daten durch Blockieren einer anschließenden Kommunikation ungültig gemacht werden.
Auch im Ethernet-Protokoll kann ein Signal erzeugt werden, das ein Schema annimmt, das sich von dem senderseitig angenommenen Übertragungsschema unterscheidet, um auf diese Weise einen Empfangsfehler auf der Empfängerseite (einen Entschlüsselungsfehler oder Rahmenprüfsequenzfehler) zu verursachen und letzten Endes die Daten ungültig zu machen.
Darüber hinaus können wie im CAN-Protokoll und CANFD-Protokoll Daten im Ethernet-Protokoll ungültig gemacht werden, indem die Informationen in Authentifizierung Ack im signierten Kommunikationsdatenformat auf Informationen abgeändert werden, die einen Fehlschlag der Authentifizierung anzeigen, oder indem das Buspotential so gesteuert wird, dass für eine vorbestimmte Zeitdauer eine Kommunikation blockiert ist.
Wie zuvor beschrieben, werden Informationen, die einen überschreibbaren Wert angeben, durch den Absender in der Authentifizierung Ack übermittelt, und das die Authentifizierung ausführende Netzwerkgerät überschreibt die Informationen in der Authentifizierung Ack, die in nicht autorisierten Daten enthalten sind, auf einen Wert, der ein nachfolgendes Überschreiben nicht erlaubt. Dieses System gestattet es dem Angreifer nicht, das Sendernetzwerkgerät dazu in Anspruch zu nehmen, die Buspotentialsteuerung auszuführen, und gestattet es dem Angreifer auch nicht, das Sendernetzwerkgerät zur Übermittlung von normalen Daten in Anspruch zu nehmen, indem verhindert wird, dass das Netzwerkgerät, das die Authentifizierung ausführt, die Überschreibsteuerung ausführt, wobei der Rest der Übertragungsdaten aufgrund der für nicht autorisiert erachteten Daten kontinuierlich überschrieben wird. Somit können die nicht authentifizierten Daten vom Empfängernetzwerkgerät niemals fälschlicherweise als normale Daten angesehen werden.
Die Daten, die wie zuvor beschrieben ungültig gemacht wurden, werden aufseiten des Empfängernetzwerkgeräts, das die ungültig gemachten Daten empfangen hat, als Fehlerdaten verworfen, und infolgedessen kann die Ausführung einer Verarbeitung seitens des Empfängernetzwerkgeräts, bei der unzulässige Daten verwendet werden, unterbunden werden.
In dem vorstehend beschriebenen System, bei dem ein anderes Netzwerkgerät Daten authentifiziert, die von einem Netzwerkgerät übermittelt wurden, und Daten, die an der Authentifizierung gescheitert sind, ungültig gemacht werden, lässt sich eine Übertragung unzulässiger Daten wirksam verhindern. Insbesondere durch Inanspruchnahme eines Netzwerkgeräts sowohl bei der Authentifizierungsverarbeitung als auch bei der Datenverarbeitung für über eine Netzwerkverbindung übertragene Daten ist die Notwendigkeit aus der Welt geschafft, dass die Authentifizierungsverarbeitung an mehreren Datenempfänger-Netzwerkgeräten auszuführen ist. Das in der Ausführungsform erzielte Netzwerkgerät verbessert die Zuverlässigkeit, mit der ein im Netzwerk auftretender Vortäuschungsangriff erfasst wird, und macht es möglich, wirksame Schutzmaßnahmen gegen den Angriff zu ergreifen.
(Zweite Ausführungsform)
Als Nächstes werden ein Beispiel, bei dem das an der Authentifizierungsverarbeitung beteiligte Netzwerkgerät alle Übertragungsdaten mit Datenformaten ungültig macht, die nicht mit erwarteten Formaten übereinstimmen, sowie die Annullierung von Übertragungsdaten beschrieben, deren Authentifizierung zum Zeitpunkt der Übertragungsdatenerfassung fehlgeschlagen ist. Mit Bezug auf 16 wird die Verarbeitung erläutert, die in der Steuereinheit 501 des in der Ausführungsform realisierten Netzwerkgeräts zum Zeitpunkt der Übertragungsdatenerfassung ausgeführt wird. Die Verarbeitung unterscheidet sich von der in der ersten Ausführungsform ausgeführten darin, dass sie einen zusätzlichen Schritt aufweist, d.h. den Schritt S201, bei dem eine Datenformatentscheidungsfindungsverarbeitung ausgeführt wird. Dementsprechend erfolgt eine Erläuterung mit Bezugnahme auf 16 mit dem Hauptaugenmerk auf dem Unterschied zur ersten Ausführungsform, ohne dass eine erneute Erklärung der Verarbeitung erfolgt, die in den Schritten ausgeführt wird, denen dieselben Schrittnummern wie in 15 zugeteilt sind.
Der Begriff „Datenformat“ bezieht sich in diesem Kontext auf ein Format, das eine Datenkennung umfasst, eine Netzwerkverbindungskennung, die dem Bus zugeteilt ist, auf den die durch die Datenkennung identifizierten Daten übertragen werden, ein Datenvorspannformat, das durch das vorstehend beschriebene Protokoll definiert ist, einen Zähler, der die Abfolge in den Daten angibt, einen Zeitstempel, der die Zeitvorgabe angibt, mit der die Daten übermittelt werden, einen Schlüsselgültigkeitszeitraum, eine Kommunikationsdatenlänge, die angenommen wird, wenn die Daten die signierten Kommunikationsdaten für die zuvor erläuterte Authentifizierung umfassen, eine Signaturlänge, die angenommen wird, wenn die Daten die signierten Kommunikationsdaten umfassen, und dgl.
In Schritt S201 führt die Steuereinheit 501 die Datenformatentscheidungsfindungsverarbeitung für die erfassten, in der Übertragung stehenden Daten aus, und bei Entscheidung, dass das Datenformat der Daten mit einem erwarteten Datenformat übereinstimmt („Ja“ in Schritt S201), fährt sie damit fort, die Verarbeitung mit dem nachfolgenden Schritt S101 auszuführen, wie vorstehend erläutert wurde. Genauer ausgedrückt, gibt es hier, wenn das Datenformat der erfassten Übertragungsdaten mit dem erwarteten Datenformat übereinstimmt, verschiedene Bedingungen wie beispielsweise Folgende: die Datenkennung 1201 und die Empfängerverbindungskennung entsprechend den Übertragungsdaten sind in der Filtertabelle 505 enthalten, der Authentifizierungszielmerker für die Übertragungsdaten ist auf „Ja“ eingestellt und die Übertragungsdaten entsprechen einer Datenkennung 1501 in der Schlüsselverwaltungstabelle 504, die Übertragungsdaten entsprechen dem Protokoll 1502 und den Schlüsseldaten 1503, die in der Schlüsselverwaltungstabelle 504 enthalten sind, und der den Übertragungsdaten entsprechende Schlüsselgültigkeitszeitraum 1504 zeigt an, dass der Schlüssel für die Übertragungsdaten noch gültig ist, der Schlüsselgültigkeitsmerker 1505 für die Übertragungsdaten zeigt „gültig“ an, die Kommunikationsdatenlänge der Übertragungsdaten stimmt mit der Kommunikationsdatenlänge 1506 überein, und die Signaturlänge in den Übertragungsdaten stimmt mit der Signaturlänge 1507 überein.
Die Steuereinheit 501 kann auf der Basis von anderen Kriterien als den vorstehend aufgeführten entscheiden, dass die Datenformate übereinstimmen. Solche Kriterien können Folgende umfassen: den Zähler, der als Abfolge der Übertragungsdaten in den Kommunikationsdaten enthalten ist und aufeinanderfolgende Werte anzeigt, und die Differenz zwischen dem Wert, der im Zeitstempel als Zeitvorgabe angegeben ist, mit der die Übertragungsdaten übermittelt werden, und dem aktuellen Zeitpunkt, die gleich oder kleiner als ein vorbestimmter Wert ist.
Auf der Grundlage von einigen der vorstehend beschriebenen Entscheidungsfindungskriterien, die zur Bestimmung dessen verwendet werden, ob die Datenformate übereinstimmen oder nicht, kann es wünschenswerter sein, die Kommunikationsschnittstelle 402 und nicht die Steuereinheit 501 mit der Datenformatentscheidungsfindungsverarbeitung zu betrauen. In einem solchen Fall können die Ergebnisse der auf Kriterien beruhenden Entscheidungsfindung, die von der Kommunikationsschnittstelle 402 durchgeführt worden ist, der Steuereinheit 501 berichtet werden.
Wenn die Datenformate nicht übereinstimmen (wenn die Datenformatentscheidungsfindungsergebnisse einen Fehlschlag anzeigen) („Nein“ in Schritt S201), beauftragt die Steuereinheit 501 die Kommunikationsschnittstelle 402 mit der Datenannullierung, indem sie eine Datenverarbeitungsanweisung für die Kommunikationsschnittstelle 402 ausgibt (Schritt S104) ausgibt, um die in der Übertragung stehenden Daten so zu verarbeiten, wie sie es tut, wenn ein Authentifizierungs-NG („Nein“ in Schritt S103) in der ersten Ausführungsform und der vorliegenden Ausführungsform auftritt. Wie bereits unter Bezugnahme auf die erste Ausführungsform erläutert worden ist, ist zu beachten, dass die Datenverarbeitung, die von der Kommunikationsschnittstelle 402 als Reaktion auf eine von der Steuereinheit 501 in Schritt S104 ausgegebene Anweisung ausgeführt wird, stattdessen von der Steuereinheit 501 ausgeführt werden kann.
In der Ausführungsform werden, wenn das Netzwerkgerät Authentifizierungszieldaten erfasst, alle Daten, die über die Netzwerkverbindung übertragen werden können, in der Filtertabelle 505 und der Schlüsselverwaltungstabelle 504 registriert. In diesen Tabellen ist eine Positivliste (eine Liste aller sicheren Daten) zusammengestellt, die es ermöglicht, die Übertragung jeglicher Daten zu verhindern, die nicht in der Filtertabelle aufgelistet sind (Übertragung von unzulässigen Daten).
Wie vorstehend beschrieben, fällt die Steuereinheit 501 in Schritt S201 in 16 eine Entscheidung dahingehend, ob die in der Übertragung stehenden Daten Informationen entsprechen oder nicht, die in der Filtertabelle 505 enthalten sind, was eine Handhabung in Bezug darauf ermöglicht, ob die Datenübertragung über den Bus gestattet ist oder nicht und ob die Daten Informationen entsprechen, die in der Schlüsselverwaltungstabelle 504 enthalten sind, was die Handhabung von Authentifizierungsschlüsseln für Daten ermöglicht, die zur Übertragung zugelassen sind. Die Kommunikationsschnittstelle 402 erklärt die Daten während der Datenübertragung für unzulässig, wenn in Schritt S201 entschieden wird, dass die bestimmten Daten in der Filtertabelle 505 und/oder der Schlüsselverwaltungstabelle 504 nicht aufzufinden sind, sowie wenn in Schritt S103 entschieden wird, dass die Authentifizierung fehlgeschlagen ist. Im Ergebnis kann die Übertragung von Daten, deren Datenkennung nicht in der Filtertabelle 505 und der Schlüsselverwaltungstabelle 504 enthalten ist, oder die Übertragung von Daten in einem unzulässigen Format verhindert werden. Es ist zu beachten, dass die Rechenlast einer auf Informationen vom Vorspann beruhenden Entscheidungsfindung geringer ist als bei der Authentifizierungsverarbeitung, und dementsprechend lässt sich die Rechenlast reduzieren, indem unzulässige Daten auf der Grundlage der Vorspanninformation erfasst werden.
(Dritte Ausführungsform)
Als Nächstes wird ein Beispiel beschrieben, bei dem Daten für ungültig erklärt werden, wenn ein GW 303 oder ein SW 304 Daten weitergibt, die von einer Netzwerkverbindung 301 auf eine andere Netzwerkverbindung 301 übertragen werden. Während die folgende Erläuterung unter der Annahme erfolgt, dass es sich bei dem in der Ausführungsform realisierten Netzwerkgerät um ein GW 303 handelt, kann die vorliegende Erfindung in ähnlicher Weise auch in einem SW 304 angewendet werden.
Das GW 303 kann Daten weitergeben, die von der Netzwerkverbindung 301a, an die das Sendernetzwerkgerät angeschlossen ist, zur Netzwerkverbindung 301b übertragen werden, die sich von der Netzwerkverbindung 301a unterscheidet und an die das Empfängernetzwerkgerät angeschlossen ist, wie in 2A dargestellt ist. In dieser Situation nimmt das GW 303 die Daten auf, die von der Netzwerkverbindung 301a, an das das Sendernetzwerkgerät angeschlossen ist, in dieses eingegeben wurden, verifiziert den Empfänger auf der Grundlage des Datenvorspanns und gibt die Daten an die Netzwerkverbindung 301b aus. Da die Daten mit geringer Latenz übertragen werden, analysiert die Kommunikationsschnittstelle 402 oder die Steuereinheit 501 im GW 303 den Vorspann der Daten, die in die Kommunikationsschnittstelle 402 im GW 303 eingegeben wurden, und beginnt damit, die Daten an die Netzwerkverbindung 301b auszugeben, sobald das Empfängernetzwerkgerät identifiziert ist.
Anschließend wird der Rest der Daten kontinuierlich von der Netzwerkverbindung 301a in das GW 303 eingegeben, und genau mit Eingabe der in den Daten enthaltenen Signaturdaten in das GW 303 wird die Datenauthentifizierungsverarbeitung im GW 303 ausgeführt, wie mit Bezug auf 15 oder 16 beschrieben wurde. Wenn entschieden wird, dass die Authentifizierungsergebnisse einen Fehlschlag anzeigen („Nein“ in Schritt S103), oder die Datenformate nicht übereinstimmen („Nein“ in Schritt S201), wird für die Daten, die an die Netzwerkverbindung 301b ausgegeben werden, und/oder für die die Daten, die von der Netzwerkverbindung 301a eingegeben werden, die Datenverarbeitung ausgeführt, wie sie vorstehend beschrieben ist.
Durch diese Verarbeitung können Daten mit geringer Latenz einfach mit alleiniger Vorspannverifizierung übertragen werden, und jegliche nicht autorisierten Daten können für ungültig erklärt werden, wenn anschließend entschieden wird, dass Authentifizierungsergebnisse einen Fehlschlag anzeigen.
(Vierte Ausführungsform)
Als Nächstes wird ein Beispiel beschrieben, bei dem ein die vorliegende Erfindung anwendendes Netzwerkgerät als in Betrieb stehend verifiziert wird. In einem Verfahren, das eine solche Verifikation ermöglicht, erzeugt die Steuereinheit 501 im Sendernetzwerkgerät die Authentifizierungs-Ack-Information als überschreibbare Information (zum Beispiel den rezessiven Wert (1) im CAN-Protokoll anzeigend), die Kommunikationsschnittstelle 402 führt eine CRC-Operation mittels der Informationen mit dem überschriebenen Authentifizierungs-Ack-Wert aus (zum Beispiel den dominanten Wert (0) im CAN-Protokoll anzeigend), und die Daten werden dann über die Kommunikationsschnittstelle 402 übermittelt. Diese Verarbeitung wird im Einzelnen mit Bezug auf 17 beschrieben. 17 stellt einen Ablaufplan der Verarbeitung dar, die in der Ausführungsform seitens der Steuereinheit zum Zeitpunkt der Datenerfassung ausgeführt wird. Es erfolgt keine wiederholte Erläuterung der Verarbeitung, die in Schritten ausgeführt wird, denen Schrittnummern zugeteilt sind, die mit denen in 15 übereinstimmen, die die Verarbeitung zeigt, die in der ersten Ausführungsform durch die Steuereinheit zum Zeitpunkt der Datenerfassung ausgeführt wird.
Die Steuereinheit 501 im Netzwerkgerät, die Daten erfasst hat, welche von einem Sendernetzwerkgerät übermittelt wurden und auf ein Empfängernetzwerkgerät übertragen werden, authentifiziert die Daten in Schritt S102 auf weitgehend dieselbe Art und Weise wie in der ersten Ausführungsform. Wenn in Schritt S303 entschieden wird, dass die Authentifizierung erfolgreich gewesen ist (Authentifizierung OK, eine affirmative Entscheidung wird in Schritt S303 getroffen), gibt die Steuereinheit 501 in Schritt S304 eine Anweisung für die Kommunikationsschnittstelle 402 aus, so dass die Information in der Authentifizierung Ack mit einem nicht überschreibbaren Wert überschrieben wird (z. B. mit dem dominanten Wert (0) im CAN-Protokoll). Wenn die Authentifizierungsergebnisse einen Fehlschlag anzeigen (wenn in Schritt S303 eine negative Entscheidung getroffen wird), werden die Daten nicht verarbeitet. Während die Daten übertragen werden, verarbeitet die Steuereinheit 501 im Authentifikatornetzwerkgerät die Übertragungsdaten so, dass angezeigt wird, dass die bestimmten Daten eine Authentifizierung durch Überschreiben der Authentifizierung Ack in den Übertragungsdaten durchlaufen haben.
Das Empfängernetzwerkgerät kann nach Empfang der Übertragungsdaten bestätigen, dass die Daten erfolgreich authentifiziert wurden, indem die Authentifizierung Ack überprüft wird, um zu verifizieren, dass eine Überschreibung stattgefunden hat, oder indem verifiziert wird, dass die CRC-Operationsergebnisse mit dem im CRC-Feld angegebenen Wert übereinstimmen. Darüber hinaus ist mit der in den empfangenen Daten überschriebenen Authentifizierung Ack das Empfängernetzwerkgerät auch in der Lage zu überprüfen, dass das Authentifikatornetzwerkgerät in einem normalen Betriebszustand ist. Das Empfängernetzwerkgerät bestimmt nach der Prüfung der Authentifizierung Ack und nach der Bestätigung, dass sie nicht überschrieben wurde, oder nach der Prüfung, dass die CRC-Operationsergebnisse nicht mit dem CRC-Feldwert übereinstimmen, dass die empfangenen Daten vom Authentifikatornetzwerkgerät nicht erfolgreich authentifiziert wurden und dass die empfangenen Daten nicht autorisierte Daten sind oder sich das Authentifikatornetzwerkgerät nicht im Betriebszustand befindet. Wenn diese Feststellungen getroffen werden, verwirft das Empfängernetzwerkgerät die empfangenen Daten.
Durch diese Maßnahmen ist gewährleistet, dass nicht autorisierte Daten, die unter Umständen übermittelt wurden, bei denen sich das Authentifikatornetzwerkgerät nicht im normalen Betriebszustand befindet oder die Signaturoperation nicht rechtzeitig abgeschlossen werden kann, nicht fälschlicherweise als authentifizierte Daten auf der Empfängerseite eingestuft werden, und das Netzwerkgerät an der Teilnahme am Betrieb auf fehlerhafter Basis gehindert wird. Es ist zu beachten, dass die Verarbeitung zum Anzeigen auf Grundlage der Authentifizierung Ack, dass sich das Authentifikatornetzwerkgerät im normalen Betriebszustand befindet, ausgeführt werden kann, während die normale Datenübertragung abläuft. Jedoch ist es wünschenswerter, diese Verarbeitung in einer Diagnosebetriebsart auszuführen, die ausgewählt wird, wenn die normale Datenübertragung wegen Wartung ausgesetzt ist.
In einer Variation der Ausführungsform, bei der das Authentifikatornetzwerkgerät als im normalen Betriebszustand befindlich verifiziert wird, werden Daten mit dem dominanten Wert, der im Spielraum 1406 im in 13 gezeigten signierten Kommunikationsdatenformat eingestellt ist, übertragen, bis das Authentifikatornetzwerkgerät die Verarbeitung der Signaturdaten beendet, und Daten mit dem im Spielraum 1406 eingestellten rezessiven Wert werden nach Abschluss der Signaturdatenverarbeitung übermittelt. Auch bei diesem Verfahren kann das Authentifikatornetzwerkgerät als im normalen Betriebszustand befindlich verifiziert werden.
In dem vorstehend beschriebenen alternativen Verfahren führt weder das Sendernetzwerkgerät noch das Empfängernetzwerkgerät eine CRC-Berechnung durch Aufnahme des im Spielraum 1406 gesetzten Signalwerts durch; stattdessen wird die CRC-Berechnung durchgeführt, ohne dass auf den im Spielraum 1406 eingestellten Signalwert zugegriffen wird. Im Ergebnis kann, selbst wenn das Authentifikatornetzwerkgerät eine Authentifizierungsverarbeitung unter Verwendung des Spielraums 1406 ausführt, die CRC-Berechnung für die Daten einschließlich des Spielraums 1406 ausgeführt werden.
In einer anderen Variation kann die Steuereinheit 501 des Authentifikatornetzwerkgeräts Informationen übermitteln, die anzeigen, dass die Authentifizierungsoperation von der Steuereinheit 501 in korrekter Art und Weise ausgeführt wird, wobei diese Übermittlung an das Sendernetzwerkgerät oder das Empfängernetzwerkgerät über einen Pfad erfolgt, der sich von den Netzwerkverbindungen unterscheidet, über die die Daten vom Sendernetzwerkgerät zum Empfängernetzwerkgerät übertragen werden, z.B. über eine Netzwerkverbindung, die zu Wartungszwecken verwendet wird, oder über eine zweckbestimmte Leitung. In dieser Situation können Informationen, die angeben, dass sich das Authentifikatornetzwerkgerät im Betriebszustand befindet, als Daten in feststehender Form bereitgestellt werden, die auf einer regelmäßigen Basis übermittelt werden, in Form von vorstehend erläuterten Signaturdaten, in Form von Daten, die mit einer Zeitvorgabe übermittelt werden, die der Datenauthentifizierungszeitvorgabe und dgl. entspricht, sowie in Form von Daten, die das zuvor beschriebene Datenformat annehmen. Wie vorstehend erläutert, sind die einzelnen Netzwerkgeräte durch eine über mehrere Netzwerkverbindungen oder eine zweckbestimmte Leitung erfolgende Verifizierung des Betriebszustands des Authentifikatornetzwerkgeräts in der Lage, in korrekter Weise zu bestätigen, dass sich das Authentifikatornetzwerkgerät im normalen Betriebszustand befindet, selbst wenn einer der Pfade angegriffen wird.
(Variation)
Es wird eine Variation beschrieben, bei der eine Stromchiffrierung zur Codierung einer im Entstehen begriffenen Signatur verwendet wird, um die Rechenlast hinsichtlich der Signaturerzeugung und Authentifizierung zu reduzieren. Beispiele von Stromchiffrierungen umfassen MUGI (eingetragenes Warenzeichen), MULTI-S01, RC4 (eingetragenes Warenzeichen) und Enocoro (eingetragenes Warenzeichen). Eine Stromchiffrierung ermöglicht die Verschlüsselung und Entschlüsselung von Daten in Einheiten von Bits, und ermöglicht somit die Abwicklung einer Hochgeschwindigkeitsverarbeitung. Eine Signatur kann wie in 12A und 12B gezeigt mittels einer Stromchiffrierung in der Verschlüsselungs-/Entschlüsselungsverarbeitung erzeugt werden und somit kann die Verarbeitung in Einheiten von Bits (oder Bytes) ausgeführt werden. Sobald die Signaturdaten erzeugt sind, können die Daten und die Signatur auf Einheiten von Bits aufgeteilt werden, oder die gesamten Signaturdaten können zunächst ausgegeben und dann mit den Daten vereinigt werden.
In Verbindung mit einer Stromchiffrierung wird entweder keine Hash-Operation ausgeführt, oder es wird eine Hash-Operation in Verbindung mit einer Stromchiffrierung in Einheiten ausgeführt, die mit den Bit-Einheiten oder Byte-Einheiten übereinstimmen, in denen die Stromchiffrierung durchgeführt wird. Die Verwendung einer Chiffrierung wie beispielsweise MULTI-S01, die über eine Datenmischfunktion und eine Datenmanipulations-Erfassungsfunktion verfügt, schaltet die Notwendigkeit der Hash-Operationsverarbeitung aus.
Durch Übernahme einer Chiffrierung im Verschlüsselungsprozess, die eine serielle Verarbeitung ermöglicht, wie zum Beispiel eine Stromchiffrierung, ist eine sehr schnelle Entscheidungsfindung möglich und im Ergebnis kann die Signaturoperation mit Leichtigkeit abgeschlossen werden, während die Datenübertragung noch im Gange ist.
Das Netzwerkgerät (das in einer der Ausführungsformen erzielt ist, sowie vorstehend beschriebene Variationen hiervon), das über einen Bus mit einem Sendernetzwerkgerät und einem Empfängernetzwerkgerät verbunden ist, die mit spezifischen Arten einer Steuerung für ein Fahrzeug befasst sind, weist eine Steuereinheit 501 und eine Kommunikationsschnittstelle 402 auf. Auf Grundlage einer Signatur, die in den Übertragungsdaten enthalten ist, die über den Bus vom Sendernetzwerkgerät zum Empfängernetzwerkgerät übertragen werden, authentifiziert die Steuereinheit 501 die Übertragungsdaten, um zu bestimmen, ob die Daten unter Vortäuschung durch das Sendernetzwerkgerät übertragen werden oder nicht. Wenn die Daten durch ein Sendernetzwerkgerät übertragen wurden, das sich als anderes Netzwerkgerät ausgibt, und die Authentifizierung somit fehlschlägt, werden die Daten von der Kommunikationsschnittstelle 402 für ungültig erklärt, während die Datenübertragung im Gange ist. Im Ergebnis wird die Übertragung von nicht autorisierten Daten verhindert. Dieses System beseitigt die Notwendigkeit von Sicherheitsmaßnahmen wie zum Beispiel eine Authentifizierungsverarbeitung und Schlüsselverwaltung, die anderweitig seitens des Empfängernetzwerkgeräts erforderlich wären, und ermöglicht letzten Endes einen teilweisen Netzwerkbetrieb, was erlaubt, das einzelne Netzwerkgerät nur dann hochzufahren, wenn dies erforderlich ist.
Das in der zweiten Ausführungsform verwirklichte Netzwerkgerät weist darüber hinaus eine Filtertabelle 505 auf, auf die zugegriffen wird, um zu bestimmen, ob die Übertragung spezifischer Daten über den Bus gestattet ist oder nicht, und eine Schlüsselverwaltungstabelle 504 zur Verwaltung von Schlüsseln, die von der Steuereinheit 501 bei der Authentifizierung von Daten verwendet werden. Bei diesem Netzwerkgerät wird von der Steuereinheit 501 während einer Datenübertragung eine Entscheidung dahingehend getroffen, ob die Filtertabelle 505 und die Schlüsselverwaltungstabelle 504 Informationen enthalten, die den in Übertragung stehenden Daten entsprechen. Die Kommunikationsschnittstelle macht bei laufender Datenübertragung die Daten ungültig, wenn die Steuereinheit 501 entscheidet, dass die Filtertabelle 505 und/oder die Schlüsselverwaltungstabelle 504 keine den Übertragungsdaten entsprechende Informationen enthalten, und auch dann, wenn die Authentifizierung durch die Steuereinheit 501 fehlgeschlagen ist. Im Ergebnis ist eine Übermittlung von nicht autorisierten Daten in einem Datenformat, das nicht mit dem in den Tabellen angegebenen Datenformat übereinstimmt, mit einer Rechenlast verhindert, die geringer ist im Vergleich zur Rechenlast, die besteht, wenn die Authentifizierungsverarbeitung ausgeführt wird.
Die Steuereinheit 501 in dem in der vierten Ausführungsform realisierten Netzwerkgerät führt einen Prozess für die in Übertragung stehenden Daten aus, um anzuzeigen, dass die Authentifizierung von der Steuereinheit 501 ausgeführt worden ist. Durch diese Maßnahmen kann das Authentifikatornetzwerkgerät von einem anderen Netzwerkgerät als im normalen Betriebszustand befindlich verifiziert werden.
Die Verwendung einer Signatur, die mit einer Stromchiffrierung im Codierprozess erzeugt wird, der als Teil der Authentifizierungsverarbeitung ausgeführt wird, ermöglicht eine schnellere Entscheidungsfindung, was es wiederum möglich macht, die Signaturoperation zu beenden, während die Datenübermittlung im Gange ist.
Bei den vorstehend beschriebenen Ausführungsformen handelt es sich um Beispiele, und es können verschiedene Abwandlungen vorgenommen werden, ohne vom Umfang der Erfindung abzuweichen. Merkmale, Bestandteile und spezifische Einzelheiten der Strukturen der vorstehend beschriebenen Ausführungsformen können ausgetauscht oder kombiniert werden, um weitere Ausführungsformen zu bilden, die für die jeweilige Anwendung optimiert sind. Sofern diese Abwandlungen für einen Fachmann ersichtlich sind, sollen sie implizit durch die vorstehende Beschreibung offenbart sein, ohne dabei explizit jede mögliche Kombination genau anzugeben.

Claims

Netzwerkgerät, das über einen Bus mit mehreren Netzwerkgeräten verbunden ist, umfassend: eine Authentifizierungseinheit (501), die eine Authentifizierung auf der Grundlage von Nachrichtenauthentifizierungsinformationen ausführt, die in Daten enthalten sind, welche über den Bus von einem der mehreren Netzwerkgeräte übertragen werden, das als Sendergerät fungiert; und eine Verarbeitungseinheit (402), die bei fehlgeschlagener Authentifizierung die Daten ungültig macht, wenn bestimmt wird, dass vom Sendergerät, das sich als ein anderes Netzwerkgerät unter den mehreren Netzwerkgeräten ausgibt, nicht autorisierte Daten übermittelt wurden, wobei: die Daten eine Authentifizierungsergebnisinformation enthalten, die ein Ergebnis der Authentifizierung anzeigen, die von der Authentifizierungseinheit (501) ausgeführt wird; und wenn die Authentifizierung fehlgeschlagen ist, die Verarbeitungseinheit (402) die Daten ungültig macht, indem ein Wert, der nicht überschrieben werden kann, in die Authentifizierungsergebnisinformation eingesetzt wird.
Netzwerkgerät nach Anspruch 1, weiter umfassend: eine erste Tabelle, die eine Verwaltung in Bezug darauf ermöglicht, ob die Daten über den Bus übermittelt werden dürfen oder nicht; eine zweite Tabelle (504), die eine Verwaltung eines Schlüssels ermöglicht, der zur Authentifizierung der Daten durch die Authentifizierungseinheit zu verwenden ist; und eine Datenformatentscheidungsfindungseinheit, die eine Entscheidung trifft, während die Daten übermittelt werden, und zwar eine Entscheidung darüber, ob die Daten mit der ersten Tabelle und der zweiten Tabelle übereinstimmen oder nicht, wobei: die Verarbeitungseinheit (402) die Daten ungültig macht, während die Daten übermittelt werden, wenn die Datenformatentscheidungsfindungseinheit entscheidet, dass die Daten nicht mit der ersten Tabelle und/oder zweiten Tabelle übereinstimmen, und auch, wenn die von der Authentifizierungseinheit (501) ausgeführte Authentifizierung fehlschlägt.
Netzwerkgerät nach Anspruch 2, wobei: die Datenformatentscheidungsfindungseinheit eine Entscheidung in Bezug darauf trifft, ob die Daten mit der ersten Tabelle und der zweiten Tabelle übereinstimmen oder nicht, und zwar auf der Grundlage von mindestens einem der folgenden: einer Verbindungskennung, die dem Bus zugeteilt ist, über den die Daten übermittelt werden, einem Vorspannformat, das für die Daten angenommen wird, einem Zähler, der eine Abfolge in den Daten angibt, einem Zeitstempel, der eine Zeitvorgabe angibt, mit der die Daten übermittelt werden, einem Gültigkeitszeitraum für den Schlüssel, einer Kommunikationsdatenlänge, die angenommen wird, wenn die Daten signierte Kommunikationsdaten enthalten, die zur Authentifizierung durch die Authentifizierungseinheit (501) verwendet werden, und einer Signaturlänge, die angenommen wird, wenn die Daten die signierten Kommunikationsdaten enthalten.
Netzwerkgerät nach mindestens einem der Ansprüche 1 bis 3, wobei: der Bus eine erste Verbindung umfasst, an die das Sendergerät angeschlossen ist, und eine zweite Verbindung, über die die Daten übermittelt werden; und wenn die von der Authentifizierungseinheit (501) ausgeführte Authentifizierung fehlgeschlagen ist, die Verarbeitungseinheit die Daten ungültig macht, die gerade von der ersten Verbindung zur zweiten Verbindung übertragen werden.
Netzwerkgerät nach mindestens einem der Ansprüche 1 bis 4, wobei: die Verarbeitungseinheit darüber hinaus einen Prozess für die Daten ausführt, während die Daten übertragen werden, um anzuzeigen, dass die Authentifizierung von der Authentifizierungseinheit (501) ausgeführt worden ist.
Netzwerkgerät nach mindestens einem der Ansprüche 1 bis 5, wobei: wenn die Authentifizierung erfolgreich gewesen ist, die Verarbeitungseinheit einen Prozess für die Daten ausführt, um anzuzeigen, dass die Authentifizierung gerade von der Authentifizierungseinheit (501) ausgeführt wird.
Netzwerksystem, umfassend: ein Netzwerkgerät nach Anspruch 1; und das Sendergerät.
Netzwerkgerät nach Anspruch 1, wobei: das Netzwerkgerät eine elektronische Steuereinheit (ECU; 302) ist; der Bus ein Controller Area Network Bus (CAN-Bus) ist; und die Authentifizierungseinheit (501) die Authentifizierung ausführt auf der Grundlage der Daten, die von der einen der mehreren elektronischen Steuereinheiten (ECUs; 302) übertragen werden, die als eine Sender-ECU fungiert und für die Daten eine negative Entscheidung fällt, die als nicht autorisierte Daten übertragen wurden, falls sich die Sender-ECU als eine andere der mehreren elektronischen Steuereinheiten (ECUs; 302) ausgibt.