DE102017219661A1

DE102017219661A1 - Verfahren zum Betreiben eines Steuergeräts

Info

Publication number: DE102017219661A1
Application number: DE102017219661.0A
Authority: DE
Inventors: Michael Weber
Original assignee: Robert Bosch GmbH
Current assignee: Robert Bosch GmbH
Priority date: 2017-11-06
Filing date: 2017-11-06
Publication date: 2019-05-09

Abstract

Die Erfindung betrifft ein Verfahren zum Betreiben eines Steuergeräts, bei dem Daten mit Hilfe einer Software übertragen werden, wobei eine Ende-zu-Ende-Absicherung vorgenommen wird und eine Safety, die die Daten mittels einer Überwachungssoftware hinsichtlich der funktionalen Sicherheit überprüft und ggf. ändert, und eine Security, die einen Zugriff auf mindestens einen Schlüssel für kryptographische Funktionen hat, berücksichtigt werden, wobei die Safety transparent zwischen einer aufrufenden Komponente und der Security vorgesehen ist, so dass die Daten durch die Safety überprüft werden können, obwohl diese durch die Security abgesichert werden.

Description

Die Erfindung betrifft ein Verfahren zum Betreiben eines Steuergeräts, insbesondere eines Motorsteuergeräts, und ein Steuergerät zur Durchführung des Verfahrens.
Stand der Technik
Zur Steuerung von Abläufen und Komponenten werden in Kraftfahrzeugen sogenannte Steuergeräte eingesetzt, die die technischen Abläufe des Kraftfahrzeugs steuern und an deren Funktionsweise hohe Anforderungen gestellt sind. Bei Motorsteuergeräten (ECM: electronic control module) wird derzeit zur funktionalen Sicherheit, der sogenannten Safety, ein Drei-Ebenen-Konzept eingesetzt. Das Drei-Ebenen Konzept sieht vor, dass in einer ersten Ebene die Fahrsoftware überwacht wird, die zweite Ebene diese erste Ebene überwacht und in der dritten Ebene die Überwachung der Hardware erfolgt.
Es gibt Bestrebungen, Standards für Software, die in Steuergeräten eingesetzt wird, zu etablieren. Diese Standards betreffen u. a. die Struktur bzw. die Architektur der in Steuergeräten eingesetzten Software. Bekannt hierbei ist bspw. ein mit AUTOSAR (AUTomotive Open System ARchitecture) bezeichneter Standard. AUTOSAR bezeichnet eine Entwicklungspartnerschaft aus Automobilherstellern, Steuergeräteherstellern sowie Herstellern von Entwicklungswerkzeugen, Steuergeräte-Basissoftware und Mikrocontrollern, deren Ziel darin besteht, den Austausch von Software zwischen verschiedenen Steuergeräten zu erleichtern. Um dies zu erreichen, wurde eine einheitliche Softwarearchitektur mit einheitlichen Beschreibungs- und Konfigurationsformaten für Embedded Software im Kraftfahrzeug erarbeitet. Dabei definiert AUTOSAR Methoden zur Beschreibung von Software in einem Fahrzeug, die sicherstellen, dass Softwarekomponenten wiederverwendet, ausgetauscht, skaliert und integriert werden können.
Die beteiligten Unternehmen streben eine Zusammenarbeit bei der Entwicklung von Standards, bspw. bei der Standardisierung von Systemfunktionen und domänen-übergreifenden Schnittstellen, an.
AUTOSAR sieht eine logische Aufteilung der Software vor und zwar in die steuergerätespezifische Basissoftware und die steuergeräteunabhängige Anwendungssoftware. Die einzelnen Softwarekomponenten werden über einen virtuellen Funktionsbus miteinander verbunden, unabhängig davon, ob die Softwarekomponenten aus einem Steuergerät abgelegt sind oder über mehrere Steuergeräte verteilt vorliegen.
AUTOSAR legt den Schwerpunkt auf tief eingebettete Systeme und Rechner für domänen-übergreifende Funktionen. Die Architektur skaliert auf unterschiedliche Fahrzeug- und Plattformvarianten, berücksichtigt die Systemverfügbarkeit sowie die Anforderungen an die Systemsicherheit und unterstützt die Übertragbarkeit von Software, die Zusammenarbeit zwischen zahlreichen Partnern, die nachhaltige Nutzung natürlicher Ressourcen sowie die Wartungsfreundlichkeit innerhalb des vollständigen Produktlebenszyklus.
Hierzu bietet AUTOSAR eine Reihe von Spezifikationen an, die Basissoftwaremodule beschreiben, Anwendungsschnittstellen definieren und eine allgemeine Entwicklungsmethodik, basierend auf einem standardisierten Austauschformat, festlegen.
Aktuelle ECM-Software wird gemäß AUTOSAR-Spezifikation in drei Teile unterteilt, nämlich eine Basissoftware (BSW), eine Laufzeitumgebung bzw. Run-Time-Environment (RTE) und eine Anwendungsebene (ASW). BSW bezeichnet standardisierte Softwaremodule zur Beschreibung einer Infrastruktur, deren Vorhandensein notwendig ist, um den funktionellen Teil der oberen Softwareebene zu betreiben. RTE beschreibt eine sogenannte Mitten- bzw. Middleware, die von der Netzwerktopologie für den Datenaustausch von Inter- und Intra-Steuergeräten zwischen Applikationssoftwarekomponenten und zwischen der Basissoftware und Applikationen abstrahiert. ASW bezeichnet die Komponenten der Applikationssoftware, die mit der Laufzeitumgebung RTE interagieren. AUTOSAR definiert somit eine im Wesentlichen dreischichtige Architektur.
Zu beachten ist, dass die Prüfung der funktionalen Sicherheit (Safety) heute fast ausschließlich in der BSW stattfindet. Hauptaufgaben, die hierbei betrachtet werden, sind die kontinuierliche Momentenüberwachung, das sogenannte E-Gas-Monitoring, die Ende-zu-Ende-Absicherung der Kommunikation, Speicher-Überwachung sowie generelle Hardware-Überwachung. Bei der nächsten Generation von ECMs wird zusätzlich der Aspekt der Security, womit die Datensicherheit gemeint ist, eine wesentliche Rolle spielen. Im Rahmen dieser werden Teile der Kommunikation mit kryptographischen Methoden gesichert.
Je nach Architektur und Zusammenspiel von Security und Safety gibt es unterschiedliche Herausforderungen. Eine der wesentlichen Herausforderungen ist, dass sowohl Security als auch Safety als letztes auf den fertigen CAN-Rahmen bzw. das fertige CAN-Frame (CAN: Controller Area Network) schauen wollen, und zwar die Security aus Gründen der Verschlüsselung bzw. Signatur und die Safety aus den Gründen, dass die Überwachung bzw. das Monitoring prinzipiell der restlichen Software, die üblicherweise nach ASIL-Level QM entwickelt wurde, nicht traut und dass das Monitoring ggf. Momentenanforderungen instandsetzen bzw. patchen muss. Dies trifft vorwiegend Steuergeräte im Antriebstrang des Fahrzeugs wie z. B. für Getriebe, Motor, ESP usw. Zur Ende-zu-Ende-Absicherung wird derzeit ohne Security eine Checksumme oder CRC zusammen mit einem Botschaftszähler bzw. Alive-Zähler eingesetzt. Ein Botschaftszähler wird verwendet, um sicherzustellen, dass die Botschaft nicht „eingefroren“ ist.
Ein Problem besteht insbesondere darin, dass die Safety, d. h. das Modul, welches die funktionale Sicherheit überprüft, auf Daten zugreifen muss, diese aber verschlüsselt bzw. signiert sind und die Safety keinen Zugriff auf den dafür erforderlichen Schlüssel hat.
Offenbarung der Erfindung
Vor diesem Hintergrund werden ein Verfahren gemäß Anspruch 1 und ein Steuergerät gemäß Anspruch 9 vorgestellt. Es wird weiterhin ein Computerprogramm nach Anspruch 10 und ein computerlesbares Speichermedium gemäß Anspruch 11 vorgestellt. Ausgestaltungen ergeben sich aus der Beschreibung und den abhängigen Ansprüchen.
Das vorgestellte Verfahren dient zum Betreiben eines Steuergeräts und beschäftigt sich vornehmlich mit der Übertragung von Daten während des Betriebs des Steuergeräts und mit der Übertragung von Daten für den Betrieb des Steuergeräts. Dabei werden die beiden zuvor erläuterten Aspekte Safety, d. h. die funktionale Sicherheit, und Security, d. h. die Datensicherheit, beachtet. Im Folgenden wird mit Safety ein Überwachungsmodul, typischerweise in Software implementiert, aber auch mit gewissen Hardware-Anforderungen, bezeichnet, das die funktionale Sicherheit, die Safety, gewährleisten soll und hierzu die Daten dahingehend überprüft, ob diese einen sicheren Betrieb des Kraftfahrzeugs gewährleisten. Mit Security wird ein Sicherheitsmodul für kryptographische Funktionen bezeichnet, in Software oder Hardware oder einer Kombination aus beidem implementiert, das Daten verschlüsseln und entschlüsseln und eine kryptographische Prüfsumme erzeugen kann, mit der überprüft werden kann, regelmäßig auch durch die Security, ob die Daten manipuliert wurden.
Auch wenn das Verfahren nachfolgend in Verbindung mit einer Software, die in eine BSW, RTE und ASW unterteilt ist, beschrieben wird, so ist dieses doch unabhängig davon, immer dann, wenn Security- und Safety-Anforderungen bestehen, anwendbar.
Unter der Übertragung von Daten ist hierin bspw. das Senden und Empfangen von Daten zu verstehen. Mögliche Ausführungen zum Senden und Empfangen von Daten sind nachstehend erläutert.
Senden:
Die zu sendenden Daten werden zunächst in der ASW erzeugt, durch die RTE werden diese zur Security gesendet, wobei die Daten zuvor an die Safety gegeben werden. Die Safety hat noch die Möglichkeit die Daten zu überprüfen und ggf. zu ändern. Die Security verschlüsselt die Daten oder signiert die Daten mit einer kryptographischen Prüfsumme. Die verschlüsselten Daten bzw. die Rohdaten mit der kryptographischen Prüfsumme werden dann wieder an die Safety übergeben. Hier besteht nochmals die Möglichkeit für die Safety diese zu überprüfen. Im Falle von verschlüsselten Botschaften sind gesonderte Maßnahmen zur Überprüfung notwendig z. B. Redundanz. Danach werden diese über die RTE an die ASW gegeben. Von der ASW gelangen die Daten dann über die RTE an die BSW. Von dieser werden die Daten dann gesendet.
Empfangen:
Die Daten werden von der BSW empfangen. Über die RTE und die ASW werden diese zunächst an die Safety, die transparent erscheint, und dann an die Security, die die Daten entschlüsseln bzw. die Signatur überprüfen kann, gegeben. Im Falle einer positiven Prüfung werden die Daten an die ASW gegeben. Beim Empfangen ist vorgesehen, dass die Safety die Security aufruft, die die Daten entschlüsselt oder eine neue Prüfsumme erzeugt. Im Falle von kryptographischen Prüfsummen ist vorgesehen, dass die Safety nicht wie vorgesehen die Überprüfungsfunktion der Security aufruft, sondern die Generierungsfunktion. Damit wird der Safety die Möglichkeit gegeben, die kryptographische Prüfsumme vom sendenden Steuergerät mit der von der Security neu berechneten zu vergleichen. Wenn beide stimmen, so wird die Botschaft bzw. deren Signale an die ASW weitergegeben.
Bei beiden Abläufen ist vorgesehen, dass die Safety transparent zwischen der aufrufenden Komponente, bspw. der ASW oder der BSW, und der Security ist. transparent bedeutet, dass die aufrufende Komponente und die Security durch den Eingriff der Safety in ihrer Funktionsweise nicht beeinflusst sind. Die ASW, die BSW und die Security-Software merken somit gar nicht, dass die Safety sich „eingeklinkt“ hat. Somit wird das Problem gelöst, dass sowohl die Safety als auch die Security auf die finale Botschaft schauen wollen, aber letztendlich nur eine der beiden als letzte die Botschaft betrachten kann.
Bei der Erfindung handelt es sich somit um ein Konzept, das die beiden Bereiche Safety und Security miteinander verbindet. Somit kann die Übertragung von Daten sowohl vor natürlichen Störgrößen als auch vor Manipulationen geschützt werden.
Bei dem Zusammenwirken von Safety und Security können unterschiedliche Fälle betrachtet werden:
Der Fall, dass nur Safety-Anforderungen aber keine Security-Anforderungen vorliegen, stellt sich als problemlos dar.
Für den Fall, dass die Security in der BSW verbleibt, wie z. B. im AUTOSAR-Standard 4.2.2 festgehalten (SecOC-Mechanismus), wurden bereits Konzepte vorgestellt, allerdings nicht im Autosar-Standard veröffentlicht. Keine Konzepte gibt es jedoch für den Fall, dass der Kunde die Verwaltung der Security in der ASW vornehmen möchte. Dies wird im Folgenden auch als Fall 1 bezeichnet.
Kein Konzept liegt auch für den Fall vor, dass der Kunde komplett verschlüsselte Botschaften und nicht nur gegen Manipulation gesicherte Botschaften übertragen möchte. In diesem Fall hat die Safety keine Möglichkeit, „in die Botschaften“ zu schauen, da die Security-Software mit den Security-Schlüsseln im Hardware-Security-Module gekapselt ist. Dies wird nachfolgend als Fall 2 betrachtet.
Vereinfacht wird auch der Fall, wenn der Kunde die Security in der BSW lässt, aber aus Platzgründen die CRC-/Checksummen der funktionalen Sicherheit aus der Botschaft entfernt. Dies wird hierin als Fall 3 bezeichnet.
Das neue an dem vorgestellten Konzept, das in dem vorgestellten Verfahren verwirklicht ist, besteht darin, dass die Security, obwohl diese in der BSW angesiedelt ist, eigentlich die höchstmögliche Schicht ist, um eine Ende-zu-Ende-Absicherung zu gewährleisten. Daher erfolgt bei diesem Konzept der Ein- und Abgriff der Überwachungs- bzw. Monitoring-Software (Safety) an der Zwischenschicht zur Security-Software.
Alle bisherigen Konzepte ermöglichen den Ein- und Abgriff der Überwachungs- bzw. Monitoring-Software an einer sogenannten Kommunikationsschnittstelle (COM-Schnittstelle) sehr viel tiefer im Protokollstack und erfordern daher weitreichende Änderungen an die Überwachung der Komponenten, der Komponenten des Monitoring, sowie an dem PDU-Router (PDU; Protocol Data Unit oder Payload Data Unit). Ein PDU-Router stellt eine Schnittstelle für Kommunikationsdienstleistungen dar. Außerdem ist eine weitere Komponente SecOC erforderlich. Die Umsetzung der Security-Verwaltung in der ASW ist deutlich erschwert und erfordert laufzeitproblematische Übergänge über die RTE. Zudem ist eine Umsetzung bei vollständig verschlüsselten Botschaften überhaupt nicht möglich. Die COM-Schnittstelle (Kommunikationsschnittstelle) ist unter AUTOSAR standardisiert und bspw. in 3 dargestellt. Der PDU-Router ist eine Softwarekomponente im AUTOSAR-Kommunikationsstack bzw. -stapel (COM-Stack) und ist bspw. in 3 dargestellt. SecOC (Secure Onboard Communication) ist eine Softwarekomponente in der AUTOSAR-Basissoftware ab Version V4.2.
Zur Umsetzung des Konzepts wird bspw. eine Überwachungs- bzw. Monitoring-Adapterschicht zwischen die RTE und die Security-Komponente, in diesem Fall die standardisierte CSM-Schnittstelle, eingefügt. Die Adapterschicht hat damit Zugriff auf die fertigen Rohsignale und kann diese ggf. vor der Berechnung der kryptographischen Routinen patchen. Dies wird als Senden-Fall bezeichnet. Die nachgelagerten kryptographischen Algorithmen rechnen daher auf den finalen Daten. Dies geschieht transparent für die ASW. CSM steht für Crypto Service Manager. Es handelt sich hierbei ebenfalls um eine von AUTOSAR standardisierte Softwarekomponente. Diese ist bspw. in 3 gezeigt.
Bei Empfangsbotschaften ist es aus Sicht der funktionalen Sicherheit erforderlich zu erkennen, ob die Daten während der Übertragung verändert worden sind. Dies wird aktuell mit CRC (cyclic redundancy check: zyklische Redundanzprüfung) oder Checksummen gemacht. Entfallen diese zu Gunsten eines kryptographischen Hashes (CMAC) oder Signatur, kann das Monitoring diesen nicht mehr redundant überprüfen, da es aus Security-Gründen keinen Zugriff auf die Schlüssel hat. Für den Fall, dass die Botschaft komplett verschlüsselt wird, hat die Überwachung bzw. das Monitoring, d. h. die Safety, überhaupt keinen Einblick mehr in die Botschaft. Eine kryptographische Hash-Funktion ist eine spezielle Form der Hash-Funktion, welche kollisionsresistent sein soll und immer eine Einwegfunktion ist. Eine Hashfunktion wiederum ist eine Funktion, die eine Zeichenfolge beliebiger Länge auf eine Zeichenfolge mit fester Länge abbildet.
Daher wird die Monitoring-Adapterschicht in diesem Fall den Aufruf zur Verifikation des CMACs einfach gegen den Aufruf zur Berechnung des CMACs austauschen. Die Rückgabe ist der neu berechnete kryptographische Wert. Dieser kann von der Monitoring-Adapterschicht dann mit dem in der Botschaft übermittelten Wert verglichen werden. Das Ergebnis OK/NOK wird dann an die aufrufende ASW zurückgemeldet. Im Falle komplett verschlüsselter Botschaften würde das Monitoring dann auch von der Security-Software die unverschlüsselten Daten bekommen und könnte darin weitere Überprüfungen vornehmen, bevor die Daten von dem Steuergerät verarbeitet werden.
Die Vorteile des Konzepts bestehen zumindest in einigen der Ausführungen des vorgestellten Verfahrens darin, dass:

- es keinerlei Änderungen an dem bestehenden Kommunikationsstapel erforderlich macht,
- der Kunde alle Möglichkeiten zur Verwaltung bzw. Steuerung der Security in der ASW behalten kann,
- ein Monitoring-Konzept ausschließlich in der BSW verbleiben kann, ohne eine aufwändige Umsetzung in der ASW mit zusätzlichen Maßnahmen, wie z. B. Härtung der RTE, notwendig zu machen, Härtung bezeichnet zusätzliche Maßnahmen in Hardware und/oder Software, um das Ausnutzen von Sicherheitslücken zu erschweren aber auch um die Fehleranfälligkeit beim Schreiben der Software zu verringern,
- auch ggf. vollständig verschlüsselte Botschaften gesendet und empfangen werden können, ohne dass das Monitoring nicht umgesetzt werden kann,
- die RTE-Schnittstelle weniger durchlaufen werden muss, was in Hinblick auf Konfiguration sowie Performance vorteilhaft ist.

Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und den beiliegenden Zeichnungen.
Es versteht sich, dass die voranstehend genannten und die nachstehend noch zu erläuternden Merkmale nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar sind, ohne den Rahmen der vorliegenden Erfindung zu verlassen.
Figurenliste

1 zeigt in schematischer Darstellung die AUTOSAR-Softwarearchitektur.
2 zeigt in schematischer Darstellung das Konzept der funktionalen Sicherheit.
3 zeigt in schematischer Darstellung eine sichere Kommunikation mit ASW-Security.
4 zeigt in schematischer Darstellung das gegenwärtige Konzept der Überwachung mit ASW-Security.
5 zeigt in schematischer Darstellung das gegenwärtige Konzept der Überwachung mit ASW-Security.
6 zeigt in schematischer Darstellung das Konzept der Überwachung mit ASW-Security gemäß einer Ausführung des vorgestellten Verfahrens.
7 zeigt in schematischer Darstellung das Konzept der Überwachung mit ASW-Security gemäß einer Ausführung des vorgestellten Verfahrens.
8 zeigt das traditionelle Safety-Konzept.
9 zeigt das bisherige Safety-Konzept mit Security.
10 zeigt das bisherige Safety-Konzept mit Security.
11 zeigt das bisherige Safety-Konzept mit Security.
12 zeigt das neue Konzept zur Verträglichkeit von Safety und Security.
13 zeigt das neue Konzept zur Verträglichkeit von Safety und Security.

Die Erfindung ist anhand von Ausführungsformen in den Zeichnungen schematisch dargestellt und wird nachfolgend unter Bezugnahme auf die Zeichnungen ausführlich beschrieben.
In 1 ist in einer schematischen Darstellung die AUTOSAR-Softwarearchitektur dargestellt, die insgesamt mit der Bezugsziffer 5 bezeichnet ist. Die Darstellung zeigt eine Basissoftware (BSW) 10, eine Laufzeitumgebung bzw. Run-Time-Environment (RTE) 12 und eine Anwendungsebene (ASW) 14. Die dargestellte Software kommt auf einem Mikrocontroller 16 zur Ausführung.
Die Basissoftware 10 umfasst Systemdienste 20, Speicherdienste 22, Kommunikationsdienste 24, eine Eingabe-Ausgabe-Hardware-Abstraktion 26, komplexe Treiber 28, eine Onboard-Gerätabstraktion 30, eine Speicher-Hardware-Abstraktion 32, eine Kommunikations-Hardware-Abstraktion 34, Mikrocontroller-Treiber 36, Speichertreiber 38, Kommunikationstreiber 40 und Eingabe-Ausgabe-Treiber 42. Die mit Abstraktion bezeichneten Schichten stellen Abstraktionsschichten dar, die eine Hardwareunabhängigkeit ermöglichen.
In der ASW 14 sind eine erste Anwendungssoftwarekomponente 50 mit AUTOSAR-Schnittstelle 52, eine Aktuator-Softwarekomponente 54 AUTOSAR-Schnittstelle 56, eine Sensor-Softwarekomponente 58 AUTOSAR-Schnittstelle 60 und eine zweite Anwendungssoftwarekomponente 62 AUTOSAR-Schnittstelle 64 vorgesehen.
Das Konzept der funktionalen Sicherheit, Ende-zu-Ende-Absicherung sowie kontinuierliche Momentenüberwachung ist in 2 dargestellt. Die Darstellung zeigt ein erstes Steuergerät 100 mit einem ersten Mikrocontroller 102, einer ersten Anwendungsebene bzw. ASW 104 und einer ersten RTE 106 sowie ein zweites Steuergerät 110 mit einem zweiten Mikrocontroller 112, einer zweiten Anwendungsebene 114 und einer zweiten RTE 116.
In der ersten ASW 104 erfolgt ein Ende-zu-Ende-Verpacken bzw. Packaging einer Anwendung 120. Diese wird über einen Kommunikationsstapel 122 und Einbeziehung einer Verpackung 124 zum Schutz vor Fehler eines geringen Levels übergeben an eine Erfassung 126 für Fehler und Verluste geringer Levels. Dort wird dies einmal über einen Kommunikationsstapel 130 an eine Erfassung 132 für eine E2E-Anwendung in der ASW 114 im zweiten Steuergerät 110 gegeben. Weiterhin wird dies an die redundante Softwareüberwachung 136 innerhalb der komplexen Treiber 138 weitergegeben.
Das bislang eingesetzte Konzept gemäß AUTOSAR-Spezifikation V4.2.2 ist in 3 bis 7 dargestellt, einschließlich der Probleme, die dieses Konzept im Zusammenspiel mit der Verwaltung der Security in der ASW verursacht, dabei ist jeweils der Teil mit Empfang und Senden der Botschaft dargestellt.
3 zeigt eine sichere Kommunikation mit ASW-Security. Die Darstellung zeigt die ASW 200, eine RTE 202 und eine BSW 204. In der ASW 200 ist ein ASW-Security-Modul 210, das mit einer Software-Komponente bzw. SW-Composition 212 kommuniziert und sich mit einer Legaxy-ASW 214 über einen Adapter 216 über Signale 218 austauscht.
In der BSW 204 sind in einem Modul Kommunikationsstandard 230 eine Kommunikationsschicht 232, ein PDU-Router 234 und eine Schnittstelle 236, bspw. eine Schnittstelle zu einem CAN-Bus, vorgesehen. Weiterhin ist in einem Treiber-Modul 240 ein Bus-Treiber 242, bspw. ein CAN-Bus-Treiber, und in einem Security-Modul 250 einen Kommunikationsschnittstelle 252 vorgesehen. Daten, die ausgetauscht werden, sind ein CMAC 260, ein Zählerstand 262, Konfigurationsdateien 264, ein Schlüssel 266 und Signale 268
4 zeigt eine Überwachung bzw. ein Monitoring in Verbindung mit einer ASW-Security gemäß dem aktuellen Konzept bei einem Senden auf Grundlage der Darstellung aus 3. Die Darstellung zeigt zusätzlich ein Überwachungsmodul 260.
In einem ersten Schritt sendet die ASW ein überwachungsrelevantes Signal. In einem zweiten Schritt erzeugt die ASW die gesamte PDU (Program Data Unit: Datenpaket) und Botschaftszähler. In einem dritten Schritt ruft die ASW eine CMAC-Berechnung über CSM mit HSM auf. In einem vierten Schritt sendet die ASW 1 Signalgruppe mit CMAC und 1 Signalgruppe mit Nutzlast zur COM-Schnittstelle. In einem fünften Schritt kompiliert der PDU-Router von der Signalgruppe CMAC und Signalgruppe Nutzlast zu einem PDU. In einem sechsten Schritt sendet der PDU-Router die PDU zu der Überwachung. In einem siebten Schritt berechnet bzw. patcht die Überwachung die PDU. In einem achten Schritt sendet Mo ein aktualisiertes PDU zu dem PDU-Router. In einem neunten Schritt erfordert der PDU-Router ein aktualisiertes CMAC. In einem zehnten Schritt empfängt der PDU-Router eine aktualisierte PDU. In einem elften Schritt erfragt der PDU-Router eine abschließende Bestätigung von der Überwachung. In einem zwölften Schritt sendet der PDU-Router die PDU aus.
5 zeigt eine Überwachung bzw. ein Monitoring in Verbindung mit einer ASW-Security gemäß dem aktuellen Konzept bei einem Empfangen.
In einem ersten Schritt empfängt die BSW einen neuen CAN-Rahmen. In einem zweiten Schritt gibt der PDUR das PDU weiter zum Monitoring und Kommunikation. Com gibt die Signalgruppe weiter zu ASW. In einem dritten Schritt verifiziert die ASW den aktiven Zähler. In einem vierten Schritt ruft die ASW die CSM-Schnittstelle CSM_MacVerify auf, um CMAC verifiziert zu haben. Monitoring benötigt CMM_MacGenerate anstelle von (CMAC_c)!. In einem fünften Schritt muss ASW CMAC_c für Monitoring bereitstellen. In einem sechsten Schritt muss Monitoring CMAC mit CMAC_c verifizieren. In einem siebten Schritt stellt Monitoring den Zustand des Vergleichs für ASW zur Verfügung. In einem achten Schritt verwirft oder verarbeitet sie ASW PDU abhängig von dem Ergebnis von Monitoring. In einem neunten Schritt stellt die ASW Signale bereit.
Das hierin vorgestellte Konzept ist in 6 und 7 jeweils mit Senden- und Empfangsteil beschrieben.
6 zeigt eine Ausführung des vorgestellten Verfahrens bei einem Senden von Daten (Tx). Die Darstellung zeigt zusätzlich CMAC_c 270 In einem ersten Schritt sendet die ASW monitoring-relevante Signale, In einem zweiten Schritt erzeugt die ASW den gesamten PDU einschließlich Botschaftszähler. In einen dritten Schritt ruft die ASW die CMAC-Berechnung (CSM/HSM) auf. Das Monitoring übernimmt ein Patchen bzw. Instandsetzen, falls dies erforderlich ist. In einem vierten Schritt sendet ASW eine Signalgruppe mit CMAC und eine Signalgruppe mit Nutzlast zu Kommunikation. In einem fünften Schritt kann das Monitoring optional Signale verifizieren, die nicht durch ASW geändert wurden. Dies ist nicht unbedingt erforderlich, da sich CMAC auf Rx-Seite zeigen wird. In einem sechsten Schritt geht PDU auf CAN.
7 zeigt eine Ausführung des vorgestellten Verfahrens bei einem Empfangen von Daten (Rx). Die Darstellung zeigt weiterhin einen Wert wahr/falsch 280.
In einem ersten Schritt wird ein CAN-Rahmen mit CMAC empfangen. In einem zweiten Schritt empfängt die ASW die gesamte PDU einschließlich Botschaftszähler. In einem dritten Schritt ruft ASW ein CMAC-Verifizieren auf (CSM/HSM). In einem vierten Schritt ruft das Monitoring anstelle dessen ein CMAC_Erzeigen auf. In einem fünften Schritt wird CMAC_c gegenüber CMAC verifiziert. Das Ergebnis wird an ASW gegeben. In einem sechsten Schritt gehen Die Signale zu ASW, wenn CMAC ist gleich CMAC_c.
8 zeigt das traditionelle Safety-Konzept ohne Security, Senden Tx, Rx analog (Fall 1). Die Darstellung zeigt in einem ersten Host Core (Prozessor) eine erste Ebene 402 und in einem zweiten Host Core (lockstepped Prozessor) 404 eine zweite Ebene 406. In der ersten Ebene 404 läuft eine ASW. Die Darstellung zeigt gesammelte Signale 410, die zu übertragen sind, eine Aktualisierung 412 eines Botschaftszählers, ein Berechnen 414 eines CRC und ein Senden 416 einer Nachricht 420, die Signale 422, ein sicherheitskritisches Signal 422, ein Wert 424 eines Botschaftszählers und ein CRC 426 umfasst. Diese Nachricht 420 wird auf ein Netzwerk 430, bspw. ein CAN-Bus, ein FlexRay-Bus o. ä.m übertragen.
In der zweiten Ebene 406 ein zweites redundantes Aktualisieren 440 des Botschaftszählers und ein zweites redundantes Berechnen 442 des CRC.. Die Darstellung zeigt weiterhin ein Hardware-Security-Modul (HSM) 450, das in den Ablauf nicht eingebunden ist.
Es erfolgt somit eine Ende-zu-Ende-Absicherung mittels CRC oder Checksumme (CS) und Botschaftszähler. Eine kontinuierliche Momentenüberwachung ist in der zweiten Ebene 406 möglich. Gegebenenfalls ist eine Neuberechnung von CRC/ bzw. CS notwendig. Eine Absicherung in der zweiten Ebene 406 ist mit bekannten Maßnahmen in Hardware und Software möglich. Dies umfasst bspw.:

Lockstep Prozessor
Programmflusskontrolle
abgesicherter Speicherbereich mit zyklischen Checks
Komplementablage
Redundante Ablage

Es ergibt sich ein redundanter, abgesicherter Signalpfad.
Aus Sicht der Softwarearchitektur kann das alles in der Basissoftware (BSW) und transparent für die Anwendersoftware (ASW) umgesetzt werden.
Zu beachten ist, dass die Safety-Erweiterungen und die Security-Kommunikation erst im AUTOSAR-Standard 4.2.x aufgenommen wurden. Das Safety-Konzept ist jedoch dort noch sehr allgemein gehalten. Über eine kontinuierliche Momentenüberwachung, was einen essentiellen Teil des Safety-Konzepts darstellt, wird wenig bis gar nicht erwähnt. Gerade die Konzepte der kontinuierlichen Momentenüberwachung im Zusammenspiel mit der Ende-zu-Ende-Absicherung sind es aber, die das Henne-Ei-Problem verursachen.
Die Schlüssel bzw. Zertifikate zur sicheren Kommunikation werden zwar im HSM abgelegt. Die Verwaltung der Schlüssel, bei multiplen Schlüsseln die Zuordnung zu den einzelnen Botschaften, wird bei den Nutzern aber oft als ASW-Modul realisiert. Die AUTOSAR-Spezifikation zur sicheren Kommunikation (Security) berücksichtigt dies zwar, berücksichtigt an dieser Stelle aber nicht das Safety-Konzept, insbesondere die kontinuierliche Momentenüberwachung. Hier liegt aber das Henne-Ei-Problem, dass sowohl Security als auch Safety die finale Botschaft sehen möchten.
Erste Versuche, die Abhängigkeit aufzulösen, bestehen darin, sowohl CMAC als auch CRC/CS in Botschaften zu belassen. Das funktioniert zwar teilweise, allerdings geht dies zu Lasten der freien Nutzdaten in den Botschaften und der Resourcenbedarf im Steuergerät erhöht sich, wenn zusätzliche Botschaften erforderlich werden, sogar signifikant. Komplett verschlüsselte Botschaften können so überhaupt nicht benutzt werden.
9 zeigt das bisherige Safety-Konzept mit Security, wobei CMAC und CRC/CS vorhanden sind, Tx (Rx analog) (Fall 2). Die Darstellung zeigt eine ASW 500, ein RTE 502 und ein BSW 504. In der ASW 500 sind ein Steuermodul 510 und eine Verwaltung 512 von Schlüssel und Botschaftszähler vorgesehen.
In der BSW 504 sind im Rahmen einer Überwachung 520 ein Aktualisieren eine Botschaftszählers und die Berechnung eines CRC, eine Schnittstelle 522 zum Fahrzeug und eine Verwaltung 524 von Schlüssel und Botschaftszähler vorgesehen. Weiterhin sind in einem Block Kommunikationsstack 530 eine Kommunikationsschnittstelle 532, ein PDU-Router 534 und eine Schnittstelle 536 zu einem Bus vorgesehen. In einem Treiber-Modul 540 ist ein Treiber 542 für diesen Bus bereitgestellt. In einer Bibliothek 550 sind ein SecOC 552, ein Berechnungsblock 554 und eine Schnittstelle 556 vorgesehen.
Eine Ende-zu-Ende-Absicherung erfolgt mittels CRC oder CS und Botschaftszähler. Die Absicherung in Ebene 2 erfolgt mit bekannten Maßnahmen, wie bspw. einem redundanten, abgesicherten Signalpfad. Eine kontinuierliche Momentenüberwachung in Ebene 2 (BC_MC) ist möglich. Ggf. ist eine Neuberechnung von CRC/CS notwendig. Die Auflösung des Henne-Ei-Problems zwischen Safety und Security erfolgt durch Verfügbarkeit von CMAC und CRC/CS. Somit sind komplett verschlüsselte Botschaften realisierbar.
Nachteile sind:
Im PDUR muss eine komplette Zustandsmaschine realisiert werden, die sich von jeder PDU „merkt“, ob es schon in BC_Mo war oder in SecOC. Ein Platzbedarf von CMAC und CRC/CS ergibt sich in jeder Botschaft. Wird die PDU vollständig in der ASW zusammengestellt, wie dies teilweise in aktuellen Projekten der Fall ist, kommt die kontinuierliche Momentenberechnung, nachdem der CMAC schon berechnet worden ist, und es müssen daher Iterationen in der Berechnung gemacht werden. Dies bedeutet, dass auch der CMAC ggf. doppelt berechnet werden muss.
10, die auf 9 basiert, zeigt das bisherige Safety-Konzept mit Security, wobei nur CMAC und kein CRC/CS vorhanden ist, Rx. (Fall 3)
Eine Ende-zu-Ende-Absicherung mittels CMAC und Botschaftszähler ist nur mit Einschränkungen realisierbar. Die Absicherung in Ebene 2 erfolgt mit bekannten Maßnahmen, bspw. redundanter, abgesicherter Signalpfad. Komplett verschlüsselte Botschaften sind realisierbar.
Nachteile sind:
Im PDUR muss eine komplette Zustandsmaschine realisiert werden, die jede PDU an BC_Mo & SecOC weiterleitet. Dazu muss sie sich „merken“, wenn es von SecOC einen CMAC zurückbekommt, zu welcher PDU dieser gehört. Die Schnittstelle von SecOC muss geändert werden, da der neu berechnete CMAC mit dem gesendeten CMAC in BC_Mo verglichen werden muss. Bisher sieht die SecOC-Schnittstelle aber nur vor, dass CMAC-Verify aufgerufen wird. Der CMAC wird dabei aber nicht zurückgegeben. Wenn der Freshness-Zähler hier in der ASW verwaltet wird, müsste BC_Mo diesen entweder redundant verwalten oder eine separate Schnittstelle dorthin realisieren.
11 zeigt das bisherige Safety-Konzept mit Security, wobei nur CMAC und kein CRC/CS vorhanden ist, Tx. Fall 3
12 zeigt das neue Konzept mit Safety und Security, Rx. Fall 4
Die Darstellung zeigt eine ASW 600, eine RTE 602 und eine BSW 604. In der ASW 600 kommuniziert eine erste Softwarekomponente 610 mit einer zweiten Softwarekomponenten 612 und über einen Adapter 614 mittels Signalen 616 mit einer Legacy-ASW 618.
In der BSW 604 sind in einem Kommunikationsstack 630 eine Kommunikationsschnittstelle 632, ein PDU-Router 634 und eine Bus-Schnittstelle 636 vorgesehen. In einem Treiber-Modul 640 ist ein Bus-Treiber 642 vorgesehen. In einem Securitymodul 650 ist eine Kommunikationsschnittstelle 652 vorgesehen. Es ist weiterhin ein Überwachungsmodul 660 und ein Überwachungsadapter 670 vorgesehen. Informationen, die übertragen werden, sind ein CMAC 680, ein CMAC_c 682, Konfigurationsdateien 684, ein Schlüssel 686, ein Wert 688 eines Botschaftszählers 690, Signale 692 und ein Wert 694 wahr/falsch.
Dabei ist eine Ende-zu-Ende-Absicherung mittels CMAC und Botschaftszähler möglich. Die Absicherung in der zweiten Ebene erfolgt mit bekannten Maßnahmen. Hierbei wird der berechnete CMAC mit dem gesendeten CMAC verglichen Eine Änderung der Schnittstellen ist nicht erforderlich. Vielmehr reicht ein einfaches Mapping von CMAC-Verify auf CMAC-Generate aus.
PDUR, Security-Software und ASW kann unverändert übernommen werden. Eine Kompatibilität mit allen AUTOSAR-Standards nicht nur V4.2.2 ist möglich. Das Vorgehen ist unabhängig davon, ob PDUs in der ASW in Signale zerlegt werden. Unabhängig davon, wo der Freshness-Zähler verwendet wird, kann er für die Ende-zu-Ende-Absicherung verwendet werden.
Weiterhin sind vollständig verschlüsselte Botschaften realisierbar. Bei vollständig verschlüsselten Botschaften besteht für den BC_Monitoring-Adapter die Möglichkeit, die entschlüsselte Botschaft nochmals verschlüsseln zu lassen und somit die Ende-zu-Ende-Absicherung zu bestätigen. Die Schlüsselinformation hierzu ist vorhanden.
13 zeigt das neue Konzept mit Safety und Security, Tx. Fall 4, basierend auf 12.
Dabei ist eine Ende-zu-Ende-Absicherung mittels CMAC und Botschaftszähler möglich. Die Absicherung in Ebene 2 erfolgt mit bekannten Maßnahmen. Daraus ergibt sich ein redundanter, abgesicherter Signalpfad. Eine kontinuierliche Momentenüberwachung in Ebene 2 (BC_Mo) ist möglich. Vollständig verschlüsselte Botschaften sind realisierbar. PDUR, Security-Software und ASW kann unverändert übernommen werden. Kompatibilität mit allen AUTOSAR-Standards nicht nur V4.2.2 ist möglich.
Unabhängig davon, wo der Freshness-Zähler verwaltet wird, kann er für die Ende-zu-Ende-Absicherung verwendet werden. Wird die PDU vollständig in der ASW zusammengestellt, kommt die kontinuierliche Momentenüberwachung, bevor der CMAC berechnet worden ist, und es müssen daher keine Iterationen in der Berechnung gemacht werden. Außerdem werden die Durchgänge durch die RTE deutlich reduziert. Bei vollständig verschlüsselten Botschaften besteht für die BC_Mo die Möglichkeit, die finale Botschaft doppelt berechnen zu lassen.
Das neue Konzept mit Safety und Security, Rx sieht vor:
(1) In einem ersten Schritt kommt eine Botschaft auf dem physikalischen Medium an, wird von der Hardware verarbeitet und im Puffer der Software bereitgestellt. Die Botschaft wird dann über den entsprechenden Treiber an den PDU-Router weitergeleitet.
(3) Der PDU-Router wiederum leitet die Botschaft weiter, und zwar m traditionellen Safety-Konzept ohne Security an das Monitoring, um die Ende-zu-Ende-Absicherung zu überprüfen. Im bisherigen Safety-Konzept mit Security erfolgt dies an das Monitoring und die Security-Software, Falls noch eine zusätzliche Checksumme/CRC in der Botschaft enthalten ist, muss der Schritt über die Security-Software nicht gemacht werden, da auch so eine Ende-zu-Ende-Absicherung sichergestellt ist.
Die Security-Software muss den CMAC neu berechnen und über den PDUR an das Monitoring weiterleiten. Wenn jedoch die Schlüssel-Zuordnung in der ASW liegt, ist dies so einfach nicht möglich.
Die Monitoring-Software überprüft den Botschaftszähler und vergleicht den neu berechneten CMAC mit dem gesendeten, falls keine CRC/Checksumme vorhanden ist. Bei vollständig verschlüsselten Botschaften ist dies so überhaupt nicht möglich.
Im hierin vorgestellten neuen Safety-Security-Konzept sind hier überhaupt keine Änderungen und kein Monitoring Zugriff erforderlich.
(4) Die ASW kann den Botschaftszähler auswerten, falls die Botschaft nicht vollständig verschlüsselt ist. Falls dieser nicht stimmt, kann er sie gleich verworfen werden. Ansonsten wird, per Anruf an die RTE, ein CMAC-Verify angefordert. Hierzu stellt die ASW-Security-Software die Information bereit, welcher Schlüssel verwendet werden soll. Die Realisierung erfolgt in Form einer Port-Schnittstelle..
(5) Der von der Security-Software benötigte Port wird im neuen Konzept nicht durch die CSM-Security-Software bereitgestellt, sondern durch die Monitoring-Adapter-Software. Die Montoring-Software kann ggf. noch einmal den Botschaftszähler überprüfen und wandelt den CMAC-Verify-Aufruf in einen CMAC-Generate-Aufruf an die CSM/HSM-Software um. Die Schlüsselinformation ist ja jetzt bekannt. Fall dies notwendig ist, kann hier ebenfalls im abgesicherten Speicherbereich der Monitoring-Software gearbeitet werden.
(6) Es erfolgt dann die Berechnung des CMAC. Bisher erfolgte ein Verify CMAC, dies ist aber bei einem symmetrischen Verfahren ebenso aufwendig. Wenn der CMAC berechnet worden ist, kann dieser an den Monitoring-Adapter zurückgegeben werden. Die Konfiguration der Schnittstelle kann synchron oder asynchron vorgenommen werden. Im synchronen Fall besteht eine Querabhängigkeit zur Monitoring-Software. Im asynchronen Fall muss der zyklische Speichertest berücksichtigt werden.
(7) Die Monitoring-Software kann den neu berechneten CMAC mit dem gesendeten CMAC vergleichen. Eine zusätzliche Checksumme bzw. CRC kann entfallen und spart Platz auf dem Bus, bspw. LIN, CAN. Falls dieser CMAC übereinstimmt, kann die Ende-zu-Ende-Absicherung als gegeben angesehen werden. Eine kontinuierliche Momentenüberwachung findet in diesem Fall auf der Seden-Seite statt. Wenn die Botschaft vollständig verschlüsselt war, kann hier zum ersten Mal der Botschaftszähler überprüft werden. Der Ausgang der Überprüfung kann an die Aufrufende ASW zurückgemeldet werden. Hiermit wird somit der CMAC-Verify-Aufruf der ASW vom Monitoring-Adapter beendet.
(8) Abhängig vom Ergebnis der CMAC-Valisiserung im vorangegangenen Schritt kann die ASW die Botschaft verwerfen, eine Fehlerbehandlung durchführen oder die einzelnen Signale daraus extrahieren und an die anderen ASW-Module weiterreichen. Bei Standard-AOTOSAR-Modulen erfolgt dies über die RTE. Bei Nicht-Standard-AUTOSAR-Modulen muss dies über einen Adapter geschehen.
Zu beachten ist, dass die entscheidenden Schritte bei den bisherigen Konzepten (Schritt 3) auf die Schritte (5) und (7) verlagert werden. Dort sind wesentlich weniger Eingriffe in andere Softwareteile (PDUR, ASW, Monitoring, Seciurity) notwendig. Außerdem sind hier alle Informationen, wie bspw. welcher Schlüssel verwendet werden soll, vorhanden. Eine Steuerung der Security von hier ist somit möglich. Es können auch vollständig bzw. komplett verschlüsselte Botschaften behandelt werden. Zusätzliche Checksummen/CRCs für das Safety-Konzept sind nicht erforderlich. Somit bleibt mehr Platz in der Botschaft für Nutzdaten.
Das neue Konzept mit Safety und Security, Tx sieht vor (Fall 4):
(3) Anstatt vom CSM-Modul wird die Security-Schnittstelle vom Monitoring-Adapter realisiert. Neben der Funktion muss auch die entsprechende AUTOSAR-Beschreibungsdatei erstellt werden, die der RTE-Konfiguration als Eingabe dient. Hierüber wird das Mapping auf die aufrufende ASW-Security-Funktion durchgeführt. Das Monitoring-Modul hat jetzt noch die Möglichkeit, im Rahmen der kontinuierlichen Momentenüberwachung die Safety-kritischen Signale zu überprüfen und ggf. zu patchen. Hierzu müssen die von der ASW-Security-Software übergebenen Daten in den überwachten Speicherbereich kopiert werden und dort mit den Standardmethoden der Ebene-2-Absicherung bearbeitet werden. Wichtig ist hier wieder, dass bei asynchronen Schnittstellenberücksichtigt wird, dass eventuell Testmuster des zyklischen Speichertests vorhanden sein können. Hier ist die asynchrone Schnittstelle zu bevorzugen.
Nach dem Patchen werden die Daten in Ebene 1 ebenfalls aktualisiert. Danach kann das Monitoring die eigentliche Security-Funktion zum Generieren des CMAC mit den aktualisierten Nutzdaten von Ebene 1 aufrufen. Eine Komplettverschlüsselung kann hier analog realisiert werden.
(2) Die ASW-Security-Software sammelt die Signale der ASW ein und erstellt zu einem PDU die Nutzdaten daraus. Danach wird noch der Botschaftszähler bzw. Freshness-Zähler eingefügt. Zur Absicherung wird jetzt noch die die Funktion CMAC-Generate aufgerufen, um die Botschaft kryptographisch abzusichern. Die Realisierung dieses Aufrufs ist über eine Port-Schnittstelle spezifiziert, Die Aufruf-Schnittstelle kann als synchron oder asynchron konfiguriert werden. Welcher Schlüssel zu verwenden ist, wird in der ASW verwaltet und wird mit dem Funktionsaufruf übergeben.
(9) Die ASW stellt die zu sendenden Signale bereit. Bei Standard-AUTOSAR-Modulen erfolgt dies über die RTE. Bei Nicht-Standard-AUTOSAR-Modulen muss dies über einen Adapter geschehen.
(6) Die ASW nimmt das PDU mit den gepatchten safety-kritischen Signalen, dem Botschaftszähler sowie dem CMAC entgegen und übergibt es an den Kommunikationsstapel per iPDU-Aufruf mittels nutzerdefinierter Signalverarbeitung. Mit iPDU wird eine Interaktionsschicht bezeichnet.
(5) Wenn die Security-Software den CMAC zurückgibt, kann das Monitoring nochmals die Nutzdaten von Ebene 1 mit seiner Kopie in Ebene 2 vergleichen. Damit wird sichergestellt, dass nicht der richtige CMAC zu falschen Daten berechnet wurde. Damit ist die Ende-zu-Ende-Absicherung und die kontinuierliche Momentenüberwachung vollständig.
Von hier werden die Daten per Zeiger bzw. Pointer an die aufrufende ASW zurück übergeben, asynchron oder synchron. Bei einer Komplettverschlüsselung kann hier dieser Vergleich nicht mehr durchgeführt werden. Es kann hier aber über einen nochmaligen Aufruf der Verschlüsselungsfunktion oder durch andere Redundanz-Mechanismen die Ende-zu-Ende-Absicherung sichergestellt werden.
(4) Es erfolgt die Berechnung des CMAC entsprechend den anderen Verfahren.
(9) Die Botschaft wird von der Software in den Puffer der Hardware geschrieben und von dort auf das physikalische Medium übertragen. Es besteht kein Unterschied zu anderen Konzepten.
(8) Die Botschaft wird vom PDUR an den entsprechenden Treiber weitergeleitet.
/7) Der PDU-Router bekommt die Botschaft von der ASW. Im traditionellen Safety-Konzept ohne Security leitet er sie jetzt an das Monitoring weiter, wo die kontinuierliche Momentenüberwachung durchgeführt wird und die Ende-zu-Ende-Absicherung aktualisiert bzw. überprüft wird. Im bisherigen Safety-Konzept mit Security leitet er sie zuerst an das Monitoring weiter, wo ggf. die safety-kritischen Signale aktualisiert werden. Anschließend muss der PDU-Router das PDU noch an die Security-Software weiterreichen. Wenn das PDU mit dem CMAC dann zurückkommt, möchte die Monitoring-Software nochmals die safety-kritischen Signale überprüfen, bevor das PDU versendet werden kann. Dieser letzte Schritt ist nicht notwendig, falls zusätzlich noch ein CRC/CS im PDU vorhanden ist. Im neuen Safety-Security-Konzept sind hier überhaupt keine Änderungen und kein Monitoring-Zugriff notwendig.
Unterschiedliche Ausführungen des vorgestellten Verfahrens sind nachfolgend anhand der in den einzelnen Schichten durchgeführten Schritte stichwortartig erläutert:
Erster Fall: Empfang einer Botschaft (Rx)
Schicht: physisches Medium, bspw. CAN/LIN/Flexray/...

- Empfang des kompletten Rahmens
- kein Unterschied zu bisherigen Konzepten

Schicht: Schnittstellen-Schicht: CANIF, LinIF, ...

- Botschaft wird als n-PDU an die obere Protokollschicht weitergereicht, nPDU bezeichnet eine Netzwerkschicht,
- kein Unterschied zu bisherigen Konzepte

Schicht: PDU-Router

- hier werden die nPDUs als iPDUs weitergeleitet. Es ist möglich, dass diese durch den Nutzer definierte Signalverarbeitung auch direkt an die ASW weitergeleitet werden,
- bei einer Autosar-kompatiblen Software können die Signale bzw. Signalgruppen über die RTE an die ASW weitergereicht werden,
- bei einer nicht-Autosar-kompatiblen Software werden die Signale typischerweise an ein Signalumwandlungsschicht weitergereicht und danach erst an eine sogenannte Legacy-ASW, eine ASW aus der Vor-AUTOSAR-Zeit. Ein Adapter hier dargestellt als Kommunikationsschicht,
- bei allen bisherigen Konzepten wird hier die PDU an die Überwachungssoftware abgezweigt. Dort wird mit den bekannten Konzepten der Drei-Ebenen-Überwachung gearbeitet, dies umfasst bspw. den Einsatz von Lockstep-Prozessor, Monitoring-Module, abgesicherte Speicherbereiche, zyklische Tests, Komplement-Ablage, Programmflusskontrolle usw. Bisherige Konzepte setzen dazu die Kooperation des PDU-Routers voraus. Das ist mit dem hierin vorgestellten Konzept nicht mehr notwendig,
- die Absicherung der Übertragungsstrecke erfordert bisher, ohne Absicherung mit kryptographischen Methoden, auch zwingend einen CRC oder eine Checksumme so wie einen Botschaftszähler,
- sind Botschaften mit kryptographischen Methoden abgesichert, so werden Veränderungen, ob absichtlich oder unabsichtlich, auch zuverlässig detektiert. Ein CRC oder eine Checksumme ist deshalb nicht erforderlich. Aufgrund der Platzbeschränkungen auf dem Übertragungsmedium wird daher angestrebt, den CRC bzw. die Checksumme wegzulassen und nicht zusätzlich zu dem kryptographischen Datum beizubehalten.

Die Schlüssel zum Dekodieren der kryptographischen Daten sind bspw. in einem gesicherten Bereich, bspw. einem HSM (Hardware Security Module) abgelegt. Aus diesem Grunde hat das Monitoring bzw. die Überwachung im Rahmen der Safety zunächst keinen Zugriff. Daher kann die Absicherung der Übertragungsstrecke hier nicht durch das Monitoring überprüft werden. Dies gilt auch, wenn die Botschaft komplett verschlüsselt und nicht nur durch einen CMAC geschützt ist. Wenn die Schlüsselinformation in der ASW verwaltet wird, dies kann bspw. kundenspezifisch vorgegeben sein, so besteht erst einmal keine Möglichkeit für das Monitoring, darauf zuzugreifen,

- falls die Überprüfung der Botschaft durch das Monitoring erfolgreich ist, wird sie an die ASW weitergeleitet,
- beim vorliegenden Konzept kann die Botschaft sofort weitergeleitet werden.

Schicht: ASW

- die ASW bekommt das komplette PDU inklusive CMAC und Botschaftszähler,
- die ASW sendet das PDU weiter an die Security-Sofware, um das kryptographische Datums (CMAC) zu verifizieren,
- der Aufruf wird über die RTE-Schnittstelle Sender-Empfänger-Ports umgesetzt,
- die aufzurufende Schnittstelle wird vom CSM-Modul, wie dies gemäß AUTOSAR vorgesehen ist, bereitgestellt. Der Standard fordert, dass diese synchron oder asynchron umzusetzen ist.

Ein CMAC (Cipher-based message authentication code: Nachrichtenauthentifizierungscode) dient dazu, Gewissheit über den Ursprung von Daten und Nachrichten zu erhalten. Hierzu eingesetzte Algorithmen benötigen zwei Eingabeparameter, nämlich die zu schützenden Daten und einen Schlüssel.
Schicht: Monitoring-Adapter

- der Adapter wird so angelegt, dass er die Ports, die eigentlich die CSM-Schnittstelle bereitstellen soll, implementiert,
- der Adapter ändert den Aufruf von „Verifizieren“ in CMAC-„Generieren“ um. Da die Überwachungssoftware der normalen Fahrsoftware nicht vertrauen darf, muss dieser Vergleich des vom entfernten Steuergerät gesendeten CMAC mit dem neu berechneten von der Überwachungssoftware ausgeführt werden, daher wird der Aufruf verändert,
- der Botschaftszähler kann hier oder aber schon in der ASW ausgewertet werden,
- des Weiteren müssen die relevanten Daten in den abgesicherten Speicherbereichen, was eine traditionelle Monitoring-Maßnahme darstellt, einschließlich Komplementablage kopiert werden, eine Komplementablage dient zum Ablegen komplementärer Daten,
- bei den Speicher-Überwachungsmaßnahmen werden auch Testmuster geschrieben und rückgelesen. Wenn der Aufruf von der Security-Software asynchron erfolgt, so ist es möglich, dass Testmuster gelesen werden. Daher ist es zwingend notwendig, dass die CSM-Schnittstelle synchron konfiguriert wird. Sollte dies nicht möglich sein, so müssen Gegenmaßnahmen für das Testmuster ergriffen werden, d. h. Änderungen an den zyklischen Speichertests.

Schicht: Security-Software

- die Security-Software berechnet den CMAC neu und reicht in zurück an den Monitoring Adapter,
- beim alten Konzept wird nur Erfolg bzw. Misserfolg der CMAC-Verifizierung zurückgegeben.

Schicht: Monitoring Adapter

- der Monitoring Adapter vergleicht den neu-berechneten CMAC mit dem vom entfernten Steuergerät gesendeten. Falls er übereinstimmt, wird die Botschaft als gültig erkannt,
- das Ergebnis wird an die aufrufende Funktion aus der ASW zurückgemeldet.

Schicht: ASW

- falls die Verifizierung des CMAC erfolgreich war, können die einzelnen Signale der Botschaft durch die ASW an die anderen Softwarekomponenten weitergeleitet werden,
- falls dies nicht der Fall ist, soll das PDU verworfen werden

Zweiter Fall: Senden einer Botschaft (Tx)
Schicht: ASW

- die Standard-Anwendungssoftware schickt Signale an die ASW-Security-Software. Wenn es sich um nicht-AUTOSAR-konforme Software handelt, dann müssen Zwischenschicht-Adapter eingefügt werden.

Schicht: ASW-Security-Software

- die ASW-Security-Software packt die verschiedenen Signale zu einem kompletten PDU zusammen. Der Botschaftszähler wird auch noch einbezogen,
- um eine Ende-zu-Ende (E2E) Absicherung herzustellen, werden typischerweise Bibliotheks-Funktionen aufgerufen, die einen CRC oder eine Checksumme über die Nutzdaten berechnen. Das ist in der ASW problemlos möglich, da das Monitoring, falls es später ein Update machen muss, einfach nochmal die E2E-Funktion aufrufen kann,
- im Falle von Security, wird jetzt aber eine Security-Funktion aufgerufen. Die Parameter enthalten unter anderem, welcher Schlüssel verwendet werden soll. Die Information ist hier nur in der ASW im Security-Modul vorhanden. Der eigentliche Schlüssel hingegen ist nur in dem HSM vorhanden,
- die Nutzdaten werden der Security-Software per Zeiger im Original übergeben,
- Für den CMAC-Bereich wird ein Puffer übergeben,
- in der herkömmlichen Software wäre ein anschließendes Überprüfen des PDU für die kontinuierliche Momentenüberwachung im PDU-Router hierdurch zwar noch möglich. Änderungen wären aber ohne Neuberechnung des CMAC nicht mehr möglich. Dazu müsste die Botschaft aber den ganzen Weg zurück durch die RTE zur ASW-Security-Software zurück. Dort müsste dann die Security-Funktion nochmalig aufgerufen werden. Dieser Weg ist kaum praktikabel.

Schicht: Monitoring-Adapter

- das vorliegende Konzept setzt daher die Monitoring-Funktionalität zwischen den ASW-Security-Koordinator und die BSW-Security-Software. Das Monitoring ist damit die letzte Schicht, bevor die CMAC-Absicherung gemacht wird und kann für die kontinuierliche Momentenüberwachung ggf. das Moment patchen. Da die Daten per Zeiger übergeben werden, wird der CMAC trotzdem über die richtigen, finalen Daten berechnet,
- dies trifft auch im Falle komplett bzw. vollständig verschlüsselter Botschaften zu,
- aus Gründen der Absicherung müssen hier allerdings noch Maßnahmen getroffen werden, dass die originalen Daten auch tatsächlich verwendet werden. Das Monitoring muss daher die kritischen Signale in seinen abgesicherten Speicherbereich kopieren,
- dort erfolgt dann wieder die Programmflusskontrolle, die zyklische Speicherbereichsüberwachung, Komplementablage usw. Auch hier ist wieder wichtig, dass die Funktionsaufrufe verträglich mit der zyklischen Speicherprüfung gestaltet werden, am einfachsten erfolgt dies synchron.

Schicht: BSW-Security-Software inkl. HSM

- identisch in allen Fällen.

Schicht: Monitoring-Adapter

- wenn die HSM-Software dann den CMAC berechnet hat, überprüft das Monitoring nochmals die Originaldaten darauf, dass tatsächlich das gepatchte Signal noch vorhanden ist. Damit wird gewährleistet, dass nicht ein richtiger CMAC zu falschen Daten berechnet wurde,
- die redundante Ablage im abgesicherten Speicherbereich, sowie die Komplementablage ermöglichen hierbei, den höheren ASIL-Level der Monitoring-Software zu gewährleisten,
- die CMAC-Daten werden an die ASW-Security-Software weitergeleitet,
- im Falle komplett verschlüsselter Botschaften müsste hier eventuell die Botschaft zwei Mal vom HSM verschlüsselt werden, um die notwendige Redundanz für den höheren ASIL-Level sicherzustellen.

Schicht: ASW-Security-Software:

- die ASW-Security-Software bekommt zu den Originaldaten den CMAC dazu. Damit kann der komplette Botschaftsinhalt mit ggf. gepatchten Signalen, Botschaftszähler sowie zugehörigem CMAC erstellt werden. Diese wird dann als PDU entweder über die RTE oder direkt per IPDU-Callout per nutzerdefinierter Signalverarbeitung an den PDU-Router weitergeleitet.

Schicht: PDU-Router

- im neuen Konzept sind keine Änderungen am PDU-Router notwendig,
- im traditionellen Konzept ohne Security würde das Monitoring aus Gründen der kontinuierlichen Momentenüberwachung hier ggf. das Signal abgreifen, patchen und die Ende-zu-Ende-Absicherung erneuern,
- im bisherigen Monitoring-Konzept mit Security ist der Abgriff auch hier. Ein Patchen hat aber in jedem Fall eine Neuberechnung des CMAC zur Folge bzw. der CMAC wird erst hinterher berechnet. Wenn die Schlüsselzuordnung allerdings in der ASW erfolgt, so sind komplizierte Rekursionen notwendig,
- komplett verschlüsselte Botschaften können hier durch das Monitoring überhaupt nicht mehr gelesen werden.

Schicht: Interface-Schicht (CanIF, LinIF, ...)

- es gibt keine Änderungen.

Schicht: physikalische Schicht

- es gibt keine Änderungen.

Claims

Verfahren zum Betreiben eines Steuergeräts (100), bei dem Daten mit Hilfe einer Software übertragen werden, wobei eine Ende-zu-Ende-Absicherung vorgenommen wird und eine Safety, die die Daten mittels einer Überwachungssoftware hinsichtlich der funktionalen Sicherheit überprüft und ggf ändert, und eine Security, die einen Zugriff auf mindestens einen Schlüssel für kryptographische Funktionen hat, berücksichtigt werden, wobei die Safety transparent zwischen einer aufrufenden Komponente und der Security vorgesehen ist, so dass die Daten durch die Safety überprüft werden können, obwohl diese durch die Security abgesichert werden.
Verfahren nach Anspruch 1, bei dem die Software in eine Basissoftware (BSW) (10, 204, 504, 604), eine Laufzeitumgebung (RTE) (12, 106, 116, 202, 502, 602) und eine Anwendungsebene (ASW) (14, 104, 114, 200, 500, 600) unterteilt ist.
Verfahren nach Anspruch 2, bei dem Daten von dem Steuergerät (100) gesendet werden, wobei die Daten zunächst von der ASW (14, 104, 114, 200, 500, 600) als aufrufende Komponente erzeugt werden und diese Daten durch die RTE (12, 106, 116, 202, 502, 602) zu Security weitergeleitet werden, in der die Daten verschlüsselt werden, wobei die Daten zuvor an die Safety gegeben werden, die transparent zwischen der ASW (14, 104, 114, 200, 500, 600) und der Security liegt, so dass die Daten vor der Verschlüsselung durch die Safety überprüft werden.
Verfahren nach Anspruch 3, bei dem die Security anstatt der Verschlüsselung eine Prüfsumme berechnet.
Verfahren nach Anspruch 2, bei dem Daten von dem Steuergerät (100) empfangen werden, wobei die Daten von der BSW (10, 204, 504, 604) als aufrufende Komponente empfangen werden und über die RTE (12, 106, 116, 202, 502, 602) an die Security weitergegeben werden, durch die die Daten entschlüsselt werden, wobei die Daten zuvor an die Safety gegeben werden, die die Security aufruft, damit die Daten entschlüsselt werden, so dass die Safety die Daten überprüfen kann.
Verfahren nach Anspruch 5, bei dem die Security anstatt der Entschlüsselung eine kryptographische Prüfsumme erzeugt und/oder überprüft.
Verfahren nach einem der Ansprüche 2 bis 5, bei dem eine Monitoring-Adapterschicht zwischen die RTE (12, 106, 116, 202, 502, 602) und die Security eingefügt wird.
Verfahren nach Anspruch 7, bei dem die Überwachungs-Adapterschicht ein Ergebnis einer Überprüfung an die ASW (14, 104, 114, 200, 500, 600) zurückmeldet.
Steuergerät, das zur Durchführung eines Verfahrens nach einem der Ansprüche 1 bis 8 eingerichtet ist.
Computerprogramm mit Programmcodemitteln, das dazu eingerichtet ist, ein Verfahren nach einem der Ansprüche 1 bis 8 auszuführen, wenn das Computerprogramm auf einer Recheneinheit, insbesondere einer mobilen Recheneinheit, ausgeführt wird.
Maschinenlesbares Speichermedium mit einem darauf gespeicherten Computerprogramm nach Anspruch 10.