Bild 2: Verschiedene Instanzen des Treibers nutzen eine gemeinsame Struktur im Shared RAM der Hardware. (Bild: Escrypt)
Dr. Thomas M. Müller, damals E/E-Leiter bei Audi, formulierte Anfang des Jahres im Interview mit der Automobil Elektronik eine klare Entwicklungsrichtung: Das Bordnetz der nahen Zukunft wird den Großteil der Softwareapplikationen auf einer Ebene mit wenigen High-Performance-Computern zusammenziehen, die alle Funktionen ihrer jeweiligen Domäne zentral rechnen. Die IP liegt dann auf den zentralen Recheneinheiten und teils in der Hand der OEMs, die Steuergeräte in der Peripherie entwickeln sich zunehmend zu Eingabe-/Ausgabegeräten, deren eigentliche Applikation in der Rechnerebene stattfindet.
Bild 1: Zukünftige Bordnetz-Architekturen benötigen eine neue Generation von HSMs, die ein volles Realtime-Betriebssystem und ein flexibles Session-Konzept mitbringen. Escrypt
Aus Sicht der OEMs hat das beachtlichen Charme: So ist etwa deutlich weniger Engineering-Aufwand vonnöten, weil Entwicklung und Zusammenspiel der Softwareapplikationen zentral gebündelt sind. Und das wiederum bringt Kostenvorteile. Allerdings geht eine solche Architektur mit einem Mehr an Kommunikation im Fahrzeugnetzwerk einher. Denn anstatt dass die Datenverarbeitung dezentral in den Steuergeräten stattfindet, werden die Daten zentral im Domänencontroller gesammelt, verarbeitet und weiterverteilt. Eine solchermaßen erhöhte Datenlast bei gleichzeitigen Echtzeitanforderungen erfordert unweigerlich eine Umstellung auf Automotive-Ethernet. Nichtsdestotrotz wird der CAN-Bus in so manchem Subnetz zunächst weiterhin eine wichtige Rolle spielen.
Security by Design
In solch einem Architekturhub müssen Security by Design und Update by Design fest verankert sein, konstatiert Thomas M. Müller im Interview. Tatsächlich eröffnet die deutlich stärkere Entkopplung von Hardware und Software und die Verlagerung vieler Softwareanwendungen und Steuergerätefunktionen auf einen zentralen Rechner hier neue Möglichkeiten. Denn auf den zentralen Recheneinheiten im Bordnetz lassen sich auch die IT-Sicherheitsfunktionen zentral verwalten.
Das bedeutet jedoch nicht, dass die Steuergeräte in der Peripherie nicht mehr abgesichert sein müssen. Im Gegenteil: Für eine gesicherte Onboard-Kommunikation (SecOC) sind dort unter anderem Hardware-Security-Module mehr denn je unverzichtbar. Ansonsten könnte ein Angreifer über die sicherheitsrelevante Schnittstelle einer einzelnen ECU womöglich auf die zentrale Recheneinheit Einfluss nehmen und schlimmstenfalls Kontrolle über das gesamte Fahrzeug erlangen. Insofern muss jederzeit sichergestellt sein, dass die Daten, die von überall aus dem Fahrzeugnetz dort zusammenlaufen, authentisch sind.
Überdies ergeben sich dadurch, dass die zentralen Hardwareeinheiten in den neuen E/E-Architekturen per Virtualisierung parallel die Softwareanwendungen und Funktionen mehrerer Steuergeräte übernehmen, zusätzliche Herausforderungen für die Security. Hardware-Security-Module müssen hier mehr leisten als in der Vergangenheit.
Job Preemption und Echtzeit-Betriebssystem
Eck-Daten
In Bordnetzarchitekturen der Zukunft verschiebt sich das Software-Regime vom Tier1 zum OEM. Für die mehr und mehr zentralisierten Plattformen gibt schließlich der OEM die Standards vor. Entsprechend muss auch die IT-Sicherheit im fahrzeuginternen Netzwerk als Plattformlösung konzipiert sein. Aktuelle Hardware-Security-Module sind hier gefragt. Da OEMs mit zunehmender Konnektivität vermehrt eigene Security-Standards entwickeln, muss auch eine Hardware Security Firmware in der Lage sein, diese zentralen Sicherheitskonzepte jederzeit zu integrieren.
Das Besondere an HSMs ist bekanntlich, das die IT-Sicherheitsfunktionen auf dem Mikrocontroller der Recheneinheit in einem eigenen HSM-Core physikalisch gekapselt sind. Dort finden die Aktivierung und der Betrieb mithilfe eines HSM-Softwarestacks statt. Der Host-Controller des Rechners kann sich so seinen eigentlichen Aufgaben widmen, während das Abarbeiten der Security-Anforderungen im HSM-Kern geschieht – Secure On-Board Communication, Runtime Manipulation Detection, sicheres Booten, Flashen, Loggen, Debuggen und mehr. Damit sind Hardware-Security-Module gegenüber rein softwaregestützten IT-Sicherheitslösungen deutlich leistungsstärker.
Das Zusammenziehen der Softwareanwendungen und ECU-Funktionen in Zentralrechnern bedingt, dass mitunter viele Applikationen gleichzeitig um die Security-Funktionen des HSM konkurrieren. Das heißt, für den Datenstrom mehrerer Anwendungen, die parallel auf der Rechenseite laufen, muss das Hardware-Security-Modul jederzeit die nötigen IT-Sicherheitsfunktionen bereitstellen und ableisten – und das in Echtzeit. Klassische Hardware-Security-Module stoßen hier an Grenzen, von softwaregestützten Lösungen ganz zu schweigen. Vielmehr braucht es eine neue Generation von HSMs, die ein volles Realtime-Betriebssystem und ein intelligentes, flexibles Session-Konzept mitbringen (Bild 1).
Multi-Core-/Multi-Application-Support
Bild 2: Verschiedene Instanzen des Treibers nutzen eine gemeinsame Struktur im Shared RAM der Hardware. Escrypt
In einer solchen Architektur stellen in der Regel mehrere Kerne parallele Anfragen, deren Verarbeitung dann im HSM-Core von der HSM-Firmware in parallelen Sessions erfolgt. Aktuelle HSM-Softwarestacks leisten hier standardmäßig 16 parallele Sessions, wobei die genaue Anzahl der Sessions anforderungsgemäß konfigurierbar ist.
Das Geheimnis eines solchen Multi-Core- und Multi-Application-Supports durch die Security-Software im HSM liegt in der speziellen Architektur des HSM-Firmware-Treibers in der Applikation. Diese erlaubt es den verschiedenen virtualisierten Applikationen, den Treiber jeweils eigenständig zu integrieren. So ist eine unabhängige Entwicklung der Softwareteile möglich. Bei der Integration wird im Linker-Schritt sichergestellt, dass die verschiedenen Instanzen des Treibers eine gemeinsame Struktur im Shared RAM der Hardware nutzen. Hier legt jede Instanz eigene Strukturen (Sessions) an, sodass die Applikationen zwar nichts voneinander wissen, der Treiber jedoch in der Lage ist, mehrere Anfragen parallel zu verwalten (Bild 2).
Die Host-to-HSM-Brücke ist dabei als trennendes Element zwischen HSM und Host eine wichtige Security-Komponente und übernimmt andererseits die Zuflussregelung zum Hardware-Security-Modul. Im Bridgeregister wird die Queue der Anfragen aus den Host-Cores so auf- und abgebaut, dass das HSM als limitierte Ressource unter optimaler Auslastung die angeforderten Security-Funktionen schnellstmöglich ausführen kann. Mit der neuen HSM-Softwaregeneration ist die Multi-App- und Multi-Core-Fähigkeit des Hardware-Security-Moduls Wirklichkeit geworden und für die OEMs in abschließend getesteter, serienreifer Form verfügbar.
Bulk Mac Interface gewährleistet nötige Performance
Bild 3: Beim Bulk Mac Interface sammelt der Host in einem Zeitraum sämtliche Nachrichten und stellt diese in nur einem Datentransfer an das HSM ein. Escrypt
Wie bereits erwähnt, erfordern künftige E/E-Architekturen mit zentralen Fahrzeugcomputern und Domänencontrollern deutlich mehr Kommunikation, und die gilt es abzusichern. Auf der einen Seite gibt es Schnittstellen mit vielen CAN-Bus-Systemen, gleichzeitig wird mit hoher Datenrate per Automotive Ethernet kommuniziert. Sicherer fahrzeuginterner Datenaustausch unter Absicherung aller Kommunikationsprotokolle (Protocol Data Unit, PDU) gestaltet sich in solchen Architekturen anspruchsvoller. Hardware-Security-Module sind hier Mittel der Wahl, wenngleich auch deren Leistungsvermögen Grenzen unterworfen ist. Dabei ist der limitierende Faktor weniger die eigentliche Hardware Crypto Engine des HSM als vielmehr das Nadelöhr des Bridgeregisters, über das sich Daten nicht in beliebiger Menge und Geschwindigkeit austauschen lassen.
Eine Lösung für das Problem liefert hier das sogenannte Bulk Mac Interface: Der Host sammelt zunächst über einen vorbestimmten Zeitraum sämtliche Nachrichten und stellt diese dann als Anfrage an das HSM en bloc über das Bridgeregister ein. Es erfolgt lediglich ein (!) Datentransfer, die HSM-Firmware prozessiert auf der schnellen HSM-Hardwareeinheit alle gesammelten Nachrichten auf einen Schlag und schreibt die Ergebnisse zurück zum Host (Bild 3).
Der Performancegewinn ist eklatant: Kostet jeder Datentransfer zwischen Host und HSM nur 10 µs, dann geht bei hundert Nachrichten insgesamt schon 1 ms verloren – für ein Realtime-System ist dies problematisch. Per Bulk Mac Interface indes lässt sich der gesamte Prozess über einen einzigen Datentransfer abhandeln: Praktisch die gesamte Millisekunde wird dadurch eingespart. Für OEMs, die in Zukunft Netzwerke mit zentralen Fahrzeugcomputern und Domänencontroller aufsetzen und viele PDUs definieren, wird ein Bulk Mac Interface damit fast schon zur unverzichtbaren Randbedingung. Denn es gewährleistet die ausreichend schnelle Authentifizierung der vielen unterschiedlichen Nachrichten und erhält die sichere Echtzeitkommunikation im Fahrzeugnetzwerk aufrecht. Tatsächlich ist in der neuen HSM-Softwaregeneration solch ein Bulk Mac Setup bereits serienreif verwirklicht.
Hardware Security Firmware für zukünftige Bordnetzarchitektur
In künftigen Bordnetzarchitekturen wird sich das Software-Regime vom Tier1 hin zum OEM verschieben. Das Fahrzeugnetzwerk entwickelt sich mehr und mehr zu einer zentralisierten Plattform, für die der OEM die Standards vorgibt. Entsprechend muss auch die IT-Sicherheit im fahrzeuginternen Netzwerk als Plattformlösung konzipiert sein. Hardware-Security-Module spielen dabei eine wichtige Rolle. Sie schützen einerseits die Datenströme von der weiterhin CAN-Bus-dominierten Peripherie hin zu den zentralen Controllern vor Zugriff und Manipulation (SecOC). Sie müssen aber vor allem auch die Security Use Cases für die zentral auf oberer Netzwerkebene laufenden Softwareanwendungen bedienen – und das bei hoher Datenlast und unter Echtzeitanforderung. Gefragt sind demnach Hardware-Security-Module, die sowohl Multi-Core- und Multi-Application-fähig sind als auch über Bulk Mac Interface die Realtime-Kommunikation adäquat unterstützen.
Zudem entwickeln die OEMs mit zunehmender Konnektivität und wachsender Zahl automatisierter Fahrfunktionen vermehrt eigene, spezifische Security-Standards für ihre E/E-Architekturen. Entsprechend müssen diese Besonderheiten durch eine Hardware Security Firmware der neuen Generation in dedizierten OEM-Produktvarianten abgebildet werden, um solche zentralen Sicherheitskonzepte jederzeit integrieren zu können. Dabei läuft sie auf den Mikrocontrollern aktueller Bauart und stellt ihren Host-Treiber als Source Code bereit, um OEMs und Tier1s vielfältige Möglichkeiten der Wiederverwendung oder Anpassung zu eröffnen.
Die Fahrzeugplattformen von morgen bringen eine effizientere Architektur mit mehr Hard- und Softwareleistung. Entsprechend leistungsstark müssen die eingebetteten Security-Komponenten sein. Hardware-Security-Module mit Firmware aktueller Prägung sind hier ein fundamentaler Baustein.
Dipl.-Ing. Tobias Klein
Dr. Frederic Stumpf
(na)
