DE102021201444A1

DE102021201444A1 - Verfahren und Vorrichtung zum Überprüfen einer eingehenden, abgesicherten, verschlüsselten Botschaft

Info

Publication number: DE102021201444A1
Application number: DE102021201444.5A
Authority: DE
Inventors: Martin Friedrich; Gobinath Ramasamy Muthusamy
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2021-02-16
Filing date: 2021-02-16
Publication date: 2022-08-18
Also published as: US20220271941A1

Abstract

Verfahren (10) zum Überprüfen einer eingehenden Botschaft (11, 12), gekennzeichnet durch folgende Merkmale:- anhand des Nachrichtenauthentifizierungscodes (12) wird eine Authentifikation (1) der Nutzdaten (11) durch ein Hardwaresicherheitsmodul (13) vorgenommen und- das Hardwaresicherheitsmodul (13) wird einer Funktionsprüfung (2) unterzogen.

Description

Die vorliegende Erfindung betrifft ein Verfahren zum Überprüfen einer eingehenden Botschaft. Die vorliegende Erfindung betrifft darüber hinaus eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium.
Stand der Technik
Mit der stetig wachsenden Komplexität elektronischer Komponenten in Fahrzeugen steigt auch die Möglichkeit von Fehlfunktionen. Ist eine sicherheitsrelevante Komponente von einer solchen Fehlfunktion betroffen, können im schlimmsten Fall Menschen zu Schaden kommen. Der internationale Standard ISO 26262 (Road vehicles - Functional safety) soll die funktionale Sicherheit von Systemen mit elektrischen oder elektronischen Komponenten in Straßenfahrzeugen gewährleisten.
Das standardgemäße Vorgehensmodell sieht dabei vor, dass im Rahmen einer Gefährdungsanalyse und Risikoabschätzung potenzielle Gefährdungen (hazards) durch Fehlfunktionen des untersuchten Systems in spezifischen Fahrsituationen identifiziert werden. Anhand verschiedener Kriterien wird jeder sicherheitsrelevanten Gefährdung sodann eine kraftfahrzeugtechnische Sicherheitsanforderungsstufe (automotive safety integrity level, ASIL) zugeordnet. Zur Minderung als nicht sicherheitsrelevant eingestufter Gefährdungen sind an das betreffende System keine Anforderungen zu stellen, die über das übliche Qualitätsmanagement (QM) hinausgehen.
Steuerungen für Otto- und Dieselmotoren nach dem Stand der Technik basieren auf einem von der Robert Bosch GmbH erarbeiteten und vom Arbeitskreis „EGAS“ des Verbandes der Automobilindustrie (VDA) adaptierten und weiterentwickelten Sicherheitskonzept, welches in Fachkreisen als „EGAS-Überwachungskonzept“ oder „Drei-Ebenen-Konzept“ bekannt ist. Die namensgebenden Ebenen gestalten sich nach diesem Konzept wie folgt:

1. Eine Funktionsebene erfüllt Motorsteuerungsfunktionen etwa zur Erreichung eines angeforderten Drehmoments, Überwachung von Bauteilen, Diagnose von Ein- und Ausgangsgrößen sowie Fehlerreaktion. Die Integrität von Signalbotschaften wird auf dieser Ebene beispielsweise durch Prüfsummen gewährleistet.
2. Eine Funktions-Überwachungsebene dient zur Erkennung fehlerhafter Abläufe auf der Funktionsebene, zum Beispiel durch die Überwachung (monitoring) des erreichten Drehmoments oder der Fahrzeugbeschleunigung, und Auslösung der für den Fehlerfall auf der Funktionsebene vorgesehenen Reaktion.
3. Eine Rechner-Überwachungsebene umfasst ein vom Funktionsrechner unabhängiges Überwachungsmodul, welches durch ein Frage-Antwort-Verfahren (challenge-response) die ordnungsgemäße Abarbeitung der Programmbefehle des Funktionsrechners prüft und im Fehlerfall vom Funktionsrechner unabhängige Reaktionen auslöst.

DE102013206185A1 betrifft ein Verfahren zur Datenübertragung zwischen einem Sensor und einem Steuergerät (electronic control unit, ECU) mit einem Hardwaresicherheitsmodul (hardware security module, HSM), wobei die übertragenen Sensordaten gegen Manipulation gesichert werden, indem sie über einen ersten logischen Datenübertragungskanal mit einer ersten Datenübertragungsrate und ein vorzugsweise auf einer Blockchiffre beruhender Nachrichtenauthentifizierungscode (cipher-based message authentication code, CMAC) über einen zweiten logischen Datenübertragungskanal mit einer zweiten Datenübertragungsrate vom Sensor an die ECU übertragen werden. Zumindest einmal zu Beginn einer Datenübertragungssitzung wird über einen dritten logischen Datenübertragungskanal ein Sitzungsschlüssel von der ECU an den Sensor übertragen und von diesem empfangen, der zumindest für die laufende Sitzung zur Generierung des MAC bzw. CMAC herangezogen wird.
In DE102017209557A1 wird ein Verfahren zum Schutz eines Fahrzeugnetzwerks eines Fahrzeugs gegen manipulierte Datenübertragung vorgeschlagen. Dabei umfasst das Fahrzeugnetzwerk mehrere Netzwerkknoten. Mindestens ein erster Netzwerkknoten in dem Fahrzeugnetzwerk vergleicht empfangene Botschaften mit dem ersten Netzwerkknoten zugeordneten Botschaften und erkennt die manipulierte Datenübertragung, wenn eine der empfangenen Botschaften mit einer dem ersten Netzwerkknoten zugeordneten Botschaft übereinstimmt, aber der erste Netzwerkknoten sie nicht gesendet hat. Dabei vergleicht der erste Netzwerkknoten nur ausgewählte der empfangenen Botschaften mit den dem ersten Netzwerkknoten zugeordneten Botschaften oder die empfangenen Botschaften nur mit ausgewählten dem ersten Netzwerkknoten zugeordneten Botschaften.
Offenbarung der Erfindung
Die Erfindung stellt ein Verfahren zum Überprüfen einer eingehenden Botschaft, eine entsprechende Vorrichtung, ein entsprechendes Computerprogramm sowie ein entsprechendes Speichermedium gemäß den unabhängigen Ansprüchen bereit.
Erfindungsgemäß dient der MAC hierbei sowohl zur Prüfung der Echtheit (Authentifikation) als auch der Unversehrtheit (Integrität) der eingehenden Botschaft. Eine zyklische Redundanzprüfung (cyclic redundancy check, CRC) oder Auswertung herkömmlicher Prüfsummen wird auf diese Weise verzichtbar. Stattdessen wird auf Funktions- und Überwachungsebene gleichermaßen mittels eines HSM der MAC ausgewertet.
Eine Besonderheit der hierzu vorgeschlagenen Lösung besteht darin, dass sie eine doppelte MAC-Prüfung durch das HSM für alle empfangenen, sicherheitsrelevanten Botschaften vermeidet. Somit wird die Belastung des HSM gegenüber einer redundanten MAC-Berechnung reduziert. Bei einer periodischen Funktionsprüfung im Abstand von 10 ms beispielsweise wäre erfindungsgemäß eine hinreichende Funktionssicherheit gewährleistet, ohne das HSM über Gebühr zu belasten. Auch eine sogenannte Lockstep-Rechnerarchitektur oder anderweitige Hardwareerweiterungen zur Fehlererkennung sind hierzu entbehrlich.
Durch die in den abhängigen Ansprüchen aufgeführten Maßnahmen sind vorteilhafte Weiterbildungen und Verbesserungen des im unabhängigen Anspruch angegebenen Grundgedankens möglich. So kann vorgesehen sein, dass zwar die Authentifikation auf der Funktionsebene, die besagte Funktionsprüfung indes durch eine kontinuierliche Überwachung des Hardwaresicherheitsmodules auf der Überwachungsebene erfolgt. Auf diese Weise wird die Fehlerfreiheit der Hardware (HW) und Software (SW) des HSM aus der Monitoring-SW sichergestellt, ohne dass es einer Rückgabe des MAC durch das HSM bedürfte. Auch die Verwendung der für den Abgleich des MAC erforderlichen Schlüssel bleibt somit auf das HSM beschränkt.
Figurenliste
Ausführungsbeispiele der Erfindung sind in den Zeichnungen dargestellt und in der nachfolgenden Beschreibung näher erläutert. Es zeigt:

1 das Flussdiagramm eines Verfahrens gemäß einer ersten Ausführungsform.
2 schematisch ein Steuergerät gemäß einer zweiten Ausführungsform.

Ausführungsformen der Erfindung
1 illustriert ein erfindungsgemäßes Konzept zum Empfangen von Botschaften über die Fahrzeugnetzwerke (CAN, LIN, Flexray usw.) mit einem verschlüsselten Korrektheitsattribut in Form eines MAC. Die Informationssicherheit (security) und Betriebssicherheit (safety) des Verfahrens (10) werden dabei durch die Kombination zweier Maßnahmen (1, 2) sichergestellt, die im Folgenden erläutert seien:

Einerseits erfolgt eine zunächst herkömmliche Auswertung der Botschaft und deren Verifikation durch Rückgabewerte der MAC-Prüfung auf der QM-Funktionsebene (L1). Für jede empfangene sicherheitsrelevante Botschaft (11, 12) wird hierzu die Konsistenz durch das HSM (13) im Rahmen der MAC-Prüfung (15) verifiziert, ohne dass die Nutzdaten (11) hierzu mit weiteren Prüfsummen versehen werden müssten. Das Ergebnis dieses Abgleiches (15) wird an die Monitoring-SW (L2) aus der HSM-SW übergeben (1).

Die entsprechenden Nutzdaten der MAC-Prüfung werden mit der redundant empfangenen Botschaft (11, 12) über die L2-SW verglichen und anschließend mit dem Ergebnis der Konsistenzprüfung verknüpft. Somit kann die Übertragungstrecke der Nutzdaten über die L1- und HSM-SW auf etwaige Bitfehler geprüft werden. Durch die Übernahme des Ergebnisses der Konsistenzprüfung für die Botschaft (11, 12) kann auf eine erneute Prüfung der Konsistenz aus der L2-SW durch das HSM (13) verzichtet werden.
Andererseits erfolgt eine kontinuierliche Überwachung (14) des HSM (13) und entsprechenden Treibers. Da das HSM (13) keine Lockstep-Architektur oder anderweitige Hardware-Betriebssicherheitsmerkmale im Sinne von ISO 26262 besitzt und die HSM-SW nicht mit einer ASIL-Klassifikation entwickelt wurde, wird dieser Teil der Software und der Hardware ständig auf richtige Funktionalität geprüft.
Die kontinuierliche Überwachung (14) der korrekten Funktion des HSM (13) wird durch eine Frage-Antwort-Kommunikation mit Hilfe der MAC-Prüfung (15) realisiert. Dabei werden nur solche Eingaben (17) bzw. Datensätze (Nutzdaten, MAC usw.) für die MAC-Prüfung (15) in einer Umsetzungstabelle (lookup table, 16) gespeichert, die bereits während des Fahrzyklus als korrekt verifiziert wurden.
Die kontinuierliche Überwachung (14) sollte hierbei die Gefahr eines falschpositiven Abgleiches (15) berücksichtigen. Dazu werden Byte-weise die Daten aus der Lookup-Tabelle (16) für die MAC-Prüfung (15) verfälscht. Diese richtigen und falschen Eingaben (17) werden im Rahmen einer zusätzlichen MAC-Prüfung (15) nach einem vorgegebenen Muster (pattern) an die HSM-SW gestellt. Die Auswertung (21) des Ergebnisses (20) mit einem Fehlerzähler sollte dann das Muster (z. B. 1-0-2-0-1-0) erkennen.
Falls ein Fehler festgestellt wird und das Muster den Abgleich (15) nicht besteht (21), werden HSM-HW und HSM-SW als fehlerhaft eingestuft, die Nutzdaten (11) der gesamten CAN-Kommunikation verworfen (24) und stattdessen auf sichere Ersatzwerte umgestellt, um das Fahrzeug in einen betriebssicheren Zustand (safe state) zu versetzen.
Dieses Verfahren (10) kann beispielsweise in Software oder Hardware oder in einer Mischform aus Software und Hardware beispielsweise in einem Steuergerät (30) implementiert sein, wie die schematische Darstellung der 2 verdeutlicht.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

DE 102013206185 A1 [0005]
DE 102017209557 A1 [0006]

Claims

Verfahren (10) zum Überprüfen einer eingehenden Botschaft (11, 12), welche Nutzdaten (11) und einen Nachrichtenauthentifizierungscode (12) umfasst, gekennzeichnet durch folgende Merkmale: - anhand des Nachrichtenauthentifizierungscodes (12) wird eine Authentifikation (1) der Nutzdaten (11) durch ein Hardwaresicherheitsmodul (13) vorgenommen und - das Hardwaresicherheitsmodul (13) wird einer Funktionsprüfung (2) unterzogen.
Verfahren (10) nach Anspruch 1, gekennzeichnet durch folgende Merkmale: - die Authentifikation (1) erfolgt auf einer Funktionsebene (L1) und - die Funktionsprüfung (2) erfolgt durch eine kontinuierliche Überwachung (14) des Hardwaresicherheitsmodules (13) auf einer Überwachungsebene (L2).
Verfahren (10) nach Anspruch 2, gekennzeichnet durch mindestens eines der folgenden Merkmale: - die Funktionsebene (L1) genügt allgemeinen Qualitätsmaßstäben und - die Überwachungsebene (L2) genügt Sicherheitsanforderungen gemäß ISO 26262.
Verfahren (10) nach einem der Ansprüche 1 bis 3, gekennzeichnet durch folgende Merkmale: - die Authentifikation (1) und Funktionsprüfung (2) umfassen einen Abgleich (15) des Nachrichtenauthentifizierungscodes (12) und - zur Funktionsprüfung (2) wird einer Umsetzungstabelle (16) eine Eingabe (17) für den Abgleich (15) entnommen.
Verfahren (10) nach Anspruch 4, gekennzeichnet durch folgende Merkmale: - beim Abgleich (15) wird ein rechnerischer Nachrichtenauthentifizierungscode ermittelt (18) und ein Vergleich (19) des rechnerischen Nachrichtenauthentifizierungscodes mit der Eingabe (17) angestellt und - ein Ergebnis (20) des Vergleiches (19) wird für die Authentifikation (1) oder Funktionsprüfung (2) ausgegeben.
Verfahren (10) nach Anspruch 5, gekennzeichnet durch folgende Merkmale: - zur Funktionsprüfung (2) wird das Ergebnis (20) anhand der Umsetzungstabelle (16) ausgewertet (21) und - wenn der Nachrichtenauthentifizierungscode (12) den Abgleich (15) besteht (22), werden die Nutzdaten (11) genutzt (23), andernfalls verworfen (24).
Verfahren (10) nach einem der Ansprüche 1 bis 6, gekennzeichnet durch folgendes Merkmal: - die Botschaft (11, 12) wird über ein Fahrzeugnetzwerk (25) empfangen.
Computerprogramm, welches eingerichtet ist, das Verfahren (10) nach einem der Ansprüche 1 bis 7 auszuführen.
Maschinenlesbares Speichermedium, auf dem das Computerprogramm nach Anspruch 8 gespeichert ist.
Vorrichtung (30), die eingerichtet ist, das Verfahren (10) nach einem der Ansprüche 1 bis 7 auszuführen.