Trends in der Fahrzeugsicherheit:
Der Fokus auf Sicherheit hat sich durch die zunehmende Verbreitung der Zonenarchitektur im Vergleich zur traditionellen Domänenarchitektur verstärkt. In einer Domänenarchitektur sind elektronische Steuergeräte (ECUs) mit ähnlichen Funktionen in einem Subnetzwerk miteinander verbunden, wodurch zahlreiche unabhängige Domänen entstehen. Diese Domänen sind beispielsweise in Antrieb und Getriebe, Karosseriesteuerung, Klimatisierung usw. unterteilt und können je nach ihrer Relevanz für das Fahrzeug unterschiedlichen Sicherheitsanforderungen entsprechend entwickelt werden. Im Gegensatz dazu sind die ECUs im Zonenkonzept mit einem lokalen Zonencontroller und Gateways verbunden. In einer Zonenarchitektur sind die Funktionen mehrerer Domänencontroller in einem zentralen Controller zusammengefasst. Diese Konzentration reduziert Systemkosten und -komplexität, weshalb die Zonenarchitektur zunehmend der Domänenarchitektur vorgezogen wird. Ein Nachteil der Zonenarchitektur besteht darin, dass ECUs aus verschiedenen Domänen das Kommunikationsnetzwerk gemeinsam nutzen müssen, was bedeutet, dass alle ECUs in der Zonenarchitektur höhere Sicherheitsstandards erfüllen müssen.
Abbildung 1. Domänenarchitektur versus Zonenarchitektur.
Um die Sicherheit von Fahrzeugen zu gewährleisten, fordern öffentliche Stellen und internationale Normungsinstitutionen von den Herstellern die Anwendung neuer Standards wie ISO/SAE 21434 und Richtlinien wie UNECE (Wirtschaftskommission der Vereinten Nationen für Europa) WP.29 R155/R156 sowie ähnlicher, regional geltender Vorschriften.
ISO 21434 ist ein relativ neuer Cybersicherheitsstandard in der Automobilindustrie. Er konzentriert sich auf die Anforderungen an Entwicklung und Prozesse über den gesamten Produktlebenszyklus hinweg und umfasst Organisationsrichtlinien, Produktentwicklungsprozesse und das Management von Sicherheitsfragen. Damit Fahrzeuge den Cybersicherheitsstandards entsprechen, muss dieser Standard entlang der gesamten Lieferkette – von den Herstellern selbst sowie von direkten Zulieferern und Anbietern von Software- und Halbleiterkomponenten – angewendet werden.
UNECE R155 und R156 sind Cybersicherheitsrichtlinien, die bisher von 65 Ländern übernommen wurden. Automobilhersteller müssen diese implementieren, um ihre Fahrzeuge in diesen Ländern vermarkten zu können. Seit Juli 2024 ist die Einhaltung für alle neu produzierten Fahrzeuge verpflichtend.
Die UNECE-Regelung bezieht sich auf die technischen Spezifikationen der ISO 21434 und fordert die Implementierung eines Cybersecurity-Managementsystems (CSMS). Dieses System muss den gesamten Lebenszyklus des Fahrzeugs abdecken, von der Entwicklung bis zum Ende seiner Nutzungsdauer. Während dieser Zeit muss das CSMS Cyberbedrohungen überwachen und einen Prozess zu deren Abwehr implementieren. In manchen Fällen kann die Abwehrmaßnahme in einem zeitnahen Firmware-Patch für ein anfälliges Steuergerät bestehen. Daher sind drahtlose Firmware-Updates in allen Fahrzeugen notwendig geworden, um die UNECE-Regelungen zu erfüllen. Das eingebettete System des Steuergeräts muss Secure Boot, sichere Firmware-Updates und sichere Kommunikation umfassen, um robuste drahtlose Firmware-Updates zu gewährleisten.
Ein Beispiel für eine Anwendung, die drahtlose Update-Fähigkeit und ein hohes Maß an Authentifizierung erfordert, ist das kabellose Laden von persönlichen Geräten im Fahrzeuginnenraum. Das Wireless Power Consortium (WPC), das die Qi®-Spezifikationen für kabelloses Laden verwaltet, ist besorgt über manipulierte Ladegeräte, die Telefone und andere Geräte beschädigen. Qi 1.3 und das neuere Qi 2.0 erfordern, dass sich kabellose Ladegeräte für das Laden mit hoher Leistung kryptografisch authentifizieren. Um diese Authentifizierung zu ermöglichen, müssen Qi-kompatible kabellose Ladegeräte über in die Gerätehardware integrierte Produktzertifikate verfügen. Diese Zertifikate sind Public-Key-Zertifikate, die Hersteller von WPC-autorisierten Zertifizierungsstellen erhalten können. Ladegeräte müssen außerdem hochsichere CC-EAL- (Common Criteria Evaluation Assurance Level) oder JIL-Hardware (Joint Interpretation Library) integrieren, die ECC-signaturbasierte Authentifizierung, sichere Schlüsselspeicherung und die sichere Speicherung des X.509-Zertifikats ermöglicht.
Software- und Hardware-Sicherheit:
Die Secure-Boot-Funktion ist von entscheidender Bedeutung für die Vertrauensbasis des Steuergeräts (ECU). Der Secure Bootloader stellt sicher, dass die auf dem Gerät laufende Firmware authentisch ist und weder während noch nach der Produktion manipuliert wurde. Daher ist der Bootloader dafür verantwortlich, dass die verwendete Firmware vom Hersteller oder direkten Lieferanten stammt. Der Speicherbereich des Steuergeräts, in dem der Secure Bootloader gespeichert ist, muss unveränderlich sein und sollte daher schreibgeschützt und nur einmalig während der Erstprogrammierung im Werk programmierbar sein. Im Bootvorgang führt der Echtzeit-Digital-Signal-Controller den Secure Bootloader aus, um die Authentizität und Integrität der Anwendungsabbilder zu überprüfen. Authentizität und Integrität können mithilfe des Elliptic Curve Digital Signature Algorithm (ECDSA) und Hash-Algorithmen verifiziert werden. Abbildung 2B zeigt die Schritte zum Erstellen einer Anwendung mit einem signierten Abbild, und Abbildung 2C veranschaulicht den Prozess zur Verifizierung der Anwendung mithilfe eines eingebetteten Echtzeit-Digital-Signal-Controllers. Abbildung 2C zeigt die Verwendung der SHA-256-Hashfunktion zur Synthese und zur Verifizierung des Schritts mit ECDSA und dem ECDSA P-256-Algorithmus.
Abbildung 2. Sicherer Bootvorgang, Firmware-Update und Controller-Speicherbelegung.
Die Funktion für sichere Firmware-Aktualisierungen kann ein unveränderlicher Teil des Echtzeit-Digitalsignal-Controllers sein und ist für die Kommunikation mit dem zentralen Gateway über das Fahrzeugnetzwerk zuständig, um das neue Anwendungsimage zu empfangen. Da das Anwendungsimage die funktionale IP-Adresse des Knotens enthält, müssen Entwickler die Verschlüsselung und Knotenauthentifizierung über die Kommunikationsschnittstelle nutzen, um die Offenlegung des Firmware-Images zu verhindern. Abbildung 2A zeigt die Speicherbelegung eines Controllers mit Firmware-Aktualisierungsfunktion. Typischerweise benötigt dieser drei Anwendungsbereiche: einen für das aktuell aktive Image, einen zum Herunterladen des neuen Images und einen Bereich für den Werksreset, der das Standardimage als Wiederherstellungsmechanismus im Fehlerfall speichert. Die Firmware-Aktualisierung muss außerdem Authentizität und Integrität sowie den sicheren Startvorgang überprüfen und eine Aktualisierungsrichtlinie implementieren, die sicherstellt, dass die Firmware nur auf eine neuere Version aktualisiert werden kann. Darüber hinaus muss die Firmware-Aktualisierung eine Systemwiederherstellungsmethode implementieren, die in bestimmten Situationen hilfreich ist, beispielsweise wenn das aktive Anwendungsimage oder die heruntergeladene Anwendung die Authentizitätsprüfung nicht besteht.
Zur Implementierung dieser Sicherheitsfunktionen empfiehlt sich die Verwendung eines externen Hardware-Sicherheitsmoduls (HSM) in Verbindung mit einem sicheren Mikrocontroller oder digitalen Signalcontroller (DSC) oder eines Mikrocontrollers/DSC mit integriertem HSM im selben Gehäuse. Ein Mikrocontroller/DSC mit integriertem HSM ist vorteilhaft, wenn eine geringe Größe erforderlich ist. Eingebettete Sicherheitslösungen mit dem dsPIC33 DSCunterstützen beispielsweise sowohl interne als auch externe HSMs; beide werden von Automobilherstellern weitgehend akzeptiert. HSMs dienen als Sicherheitsenklave, wenn der sichere Schlüsselspeicherbereich und die kryptografischen Module vom Hauptsystem des Mikrocontrollers/DSC getrennt sind. Dies reduziert das Sicherheitsrisiko im Vergleich zu einem Mikrocontroller, der Schlüssel in seinem internen Speicher speichert. Der sichere Mikrocontroller/DSC ergänzt ein externes HSM um Funktionen wie unveränderlichen sicheren Boot-Speicher, einmalig programmierbaren Flash-Speicher und die Möglichkeit, den Debug-Modus zu deaktivieren. Eine Steuergeräteplattform, die auf einem HSM und einer Familie sicherer Mikrocontroller basiert, ist besser geeignet, da sie die Auswahl des passenden Mikrocontrollers anhand der Speicher- und Funktionsanforderungen ermöglicht.
Die Entwicklung mit einem externen oder integrierten HSM erfordert ein detailliertes Sicherheitsverständnis und eine gründliche Analyse der zahlreichen Konfigurationseinstellungen, um die spezifischen Sicherheitsanforderungen jeder Anwendung und die gewünschten Sicherheitsprofile zu erfüllen. Daher ist es wichtig, die Entwicklung mit einem Tool-Ökosystem zu beginnen, das schnelles Hardware-Prototyping und grafische Konfiguratoren ermöglicht. Ein weiterer wichtiger Aspekt ist die sichere Programmierung von Schlüsseln und geheimen Daten in das HSM während der Produktionsphase, ohne sensible Informationen preiszugeben. Dieses Problem wurde durch einige HSM-Halbleiterhersteller, die eine sichere HSM-Lieferung anbieten, gelöst. Diese Geräte vereinfachen die Produktion erheblich.
Moderne Steuergeräte (ECUs) wurden gemäß AUTOSAR (Automotive Open System Architecture) entwickelt. Daher benötigt die Sicherheitsentwicklung ein HSM und einen sicheren Mikrocontroller/DSC, der mit den am Markt erhältlichen AUTOSAR-Softwarekomponenten kompatibel ist. AUTOSAR unterstützt die Implementierung von Sicherheitsfunktionen durch verschiedene Funktionsblöcke.
Abbildung 3 zeigt ein Konzeptdiagramm der AUTOSAR-Architektur. Unten befindet sich ein DSC (Digitaler Controller) bzw. ein physischer Mikrocontroller, oben die Basissoftware (BSW). Die BSW ist weiter unterteilt in die Serviceschicht, die ECU-Abstraktionsschicht und die Mikrocontroller-Abstraktionsschicht (MCAL). Darüber liegt die Laufzeitumgebung (RTE), die eine standardisierte Schnittstelle für den Zugriff von Anwendungen auf die darunterliegenden Schichten bereitstellt. Sie ermöglicht außerdem die Kommunikation zwischen den Anwendungskomponenten höherer Ebenen, programmiert die BSW und verwaltet BSW-Ressourcen und -Instanzen. Die Anwendungsschicht ist in die AUTOSAR-Softwarekomponenten (SW-C) unterteilt. Sie besteht aus zahlreichen Softwarekomponenten, von denen jede eine spezifische Funktion für das Steuergerät bereitstellt.
Das BSW verfügt über eine Standardschnittstelle zur Nutzung von Sicherheitsfunktionen wie kryptografischen Peripheriegeräten, Vertrauensankern und HSM-Modulen. Die AUTOSAR-Architektur unterteilt die Kryptografie-Implementierung in drei Schichten: eine Dienstschicht, eine Hardware-Abstraktionsschicht und MCAL. Die Dienstschicht enthält den Crypto Service Manager (CSM). Anwendungskomponenten interagieren mit dem CSM, um auf die zugrundeliegende kryptografische Bibliothek und das HSM zuzugreifen und kryptografische Funktionen zu programmieren.
Der Crypto Stack kann so konfiguriert werden, dass er die im DSC verfügbaren Hardware-Kryptografiefunktionen oder externe kryptografische Geräte wie ein externes Hilfs-HSM nutzt. Der AUTOSAR Stack kann die Verwendung eines externen HSM über die serielle Peripherieschnittstelle (SPI) von MCAL und den entsprechenden kryptografischen Treiber des HSM-Herstellers integrieren.
Die Hauptsicherheitsfunktion wird vom Crypto Stack bereitgestellt, der Zugriff auf kryptografische Primitive und die Schlüsselverwaltung hat. AUTOSAR unterstützt drei sichere Kommunikationsprotokolle: SecOC (Secure Onboard Communication), TLS (Transport Layer Security) und IPsec (Internet Protocol Security). SecOC ist ein offener Standard der AUTOSAR-Organisation und wird für die sichere Kommunikation zwischen Steuergeräten bevorzugt. Er kann über CAN-, Ethernet- oder LIN-Netzwerke verwendet werden. Die BSW von AUTOSAR beinhaltet sichere Diagnosefunktionen und Angriffserkennung. Zusätzliche Funktionen, wie z. B. sichere Firmware-Updates, können im Crypto Stack implementiert werden.
Abbildung 3. Kryptografische Funktionen von AUTOSAR.
Fazit:
Der Trend im Markt für vernetzte Fahrzeuge wirft bei Behörden, Automobilherstellern und Fahrern Bedenken hinsichtlich Datenschutz und Sicherheit auf. Neue Vorschriften fordern daher die Integration von Cybersicherheit in Fahrzeuge, um den Datenschutz zu gewährleisten und die Sicherheit zu verbessern. Cybersicherheit umfasst die gesamte Lieferkette, von den Automobilherstellern bis zu den Komponentenlieferanten. Entwickler können ein HSM-Modul zusammen mit einem sicheren Mikrocontroller/DSC oder einen Mikrocontroller/DSC mit integriertem HSM in einem einzigen Gehäuse verwenden. Darüber hinaus erleichtert ein Ökosystem aus Rapid-Prototyping-Tools, Bibliotheken und grafischen Konfiguratoren für HSMs die Entwicklung. Die Verfügbarkeit von AUTOSAR-Bibliotheken und -Support reduziert den Entwicklungsaufwand zusätzlich. Das ideale Ökosystem für einen DSC oder Mikrocontroller in einem Fahrzeug muss vollständig mit AUTOSAR, der funktionalen Sicherheit nach ISO 26262, weiteren Zertifizierungen zur funktionalen Sicherheit und Sicherheitsbibliotheken kompatibel sein. Weitere Informationen zu AUTOSAR, Cybersicherheit in der Automobilindustrie und funktionaler Sicherheit nach ISO 26262 finden Sie im DSC dsPIC33 Automotive-Ökosystem
Autor: Nelson Alexander, Chefingenieur und Produktmarketingmanager der Microchip Technology.
