Security-Anforderungen im Auto: Aktueller Stand und Lösungen

Die fahrzeugeigenen elektronischen Steuergeräte (ECUs; Electronic Control Units) und ihre Kommunikation innerhalb des Fahrzeugs und mit der Außenwelt stellen eine große Sicherheitsbedrohung dar. Verbindungen über Bluetooth, USB, LTE, 5G, Wi-Fi/WLAN etc. bringen den Nutzern viel Komfort – aber auch Hacker sind von dieser wachsenden Angriffsfläche begeistert. Sicherheitsverletzungen führen zu teuren Rückrufen, Gerichtsverfahren und können den Ruf der Marke schädigen. Fakt ist, dass Software anfällig für Fehler ist, und Fehler werden von Hackern ausgenutzt. Es gibt viele Möglichkeiten, um Fehler zu minimieren und nach deren Entdeckung, Korrekturmaßnahmen zu ergreifen. Solange jedoch Menschen neuen Code schreiben, können neue Fehler auftreten.

Zugriff auf den CAN-Bus

Der Zugriff auf den CAN-Bus (Controller Area Network) des Fahrzeugs ist ein häufiges Ziel von Hackern. Es wurden bereits Hacks demonstriert, die es Angreifern ermöglichten, einen Fehler in der Bluetooth-Übertragung und folglich einen Fehler im Betriebssystem des Fahrzeugs zu nutzen, der einen Fernzugriff zur Manipulation von Nachrichten auf dem CAN-Bus ermöglichte. Aktuelle Fahrzeuge enthalten bis zu 100 ECUs, von denen sicherheitskritische ECUs über den Bus kommunizieren. Der CAN-Bus hat mehrere Vorteile: Er verwendet ein einfaches Protokoll, das kostengünstig, robust und immun gegen elektrische Störungen ist, was eine zuverlässige Option für die Kommunikation zwischen sicherheitskritischen Knoten darstellt. Der Nachteil ist, dass das Protokoll seit Jahrzehnten keinerlei Sicherheit bietet.

Ein Hacker kann also, sobald er Zugang erhält, gefälschte Nachrichten senden, die die Kommunikation im Fahrzeug beeinträchtigen können. Einige Beispiele sind das Ein- oder Ausschalten der Scheibenwischer, das Ausschalten von Scheinwerfern, das Ablenken des Fahrers durch Manipulation des Audiosignals, das Erstellen falscher Warnmeldungen im Kombi-Instrument, die falsche Anzeige der Geschwindigkeit, das Verstellen von Sitzen oder sogar das Verlassen der Fahrbahn. Die gute Nachricht ist, dass mit der Einführung von CAN FD zusätzliche Bytes in der Nutzlast der Nachricht zur Verfügung stehen, um die Sicherheit zu erhöhen.

Dabei wird ein MAC (Message Authentication Code) eingefügt, um die Authentizität der Nachricht verschlüsselt zu überprüfen und so alle gefälschten Nachrichten herauszufiltern. Es stehen zwei Arten von MACs zur Auswahl: ein Hash-basierter HMAC oder ein AES-verschlüsselter Block-Cypher-Mode CMAC. In den meisten Fällen kommt ein CMAC zum Einsatz.

Die OEMs haben daraufhin ihre Cybersicherheits-Spezifikationen aktualisiert. Fast alle OEMs verlangen nun, dass sicherheitskritische ECUs aufgerüstet werden, um ihre neuen Cybersicherheits-Anforderungen zu erfüllen. Einige OEMs verlangen sogar, dass 100 Prozent der vernetzten ECUs aufgerüstet werden.

Der grundlegende Sicherheitsanspruch ist, sicheres Booten zu implementieren. Dabei wird verschlüsselt überprüft, dass der Boot- und Anwendungscode, der auf einem Host-Controller ausgeführt wird, unverändert ist und sich beim Einschalten, Zurücksetzen und häufig auch nach dem Booten in einem vertrauenswürdigen Zustand befindet. An zweiter Stelle steht die Anforderung, sichere Firmware-Updates zu unterstützen. Jede Software kann mit Fehlern behaftet sein kann. Daher ist es oft notwendig, Firmware-Bug-Patches zu erstellen, die im Feld zum Einsatz kommen.

Diese Firmware-Updates erfordern ebenfalls verschlüsselte Sicherheitsimplementierungen, die verlangen, dass eingehende Firmware-Nutzdaten mit einem symmetrischen (AES-)Schlüssel verschlüsselt und mit einem asymmetrischen privaten Schlüssel signiert werden, meistens ECC (Elliptic Curve Cryptography). Wird dem Host-Controller ein Upgrade-Image präsentiert, wird auf diese Weise keine Aktion ausgeführt, bis die Signatur der Nutzdaten durch den im Controller eingebetteten öffentlichen ECC-Schlüssel überprüft wurde. Sobald die Signatur verifiziert wurde, lässt sich das Image entschlüsseln und die Controller-Firmware mit dem Bug-Patch oder der Funktionserweiterung aktualisieren. Die dritte Ergänzung hinsichtlich der Sicherheit ist die oben beschriebene Nachrichtenauthentifizierung.

Batterie-Authentifizierung für E-Autos

Einzigartig im Bereich der Elektrofahrzeuge ist der wachsende Bedarf an Batterie-Authentifizierung. Die meisten Batteriepacks sind mit austauschbaren Batteriemodulen innerhalb des größeren Packs konzipiert, sodass sich dies bei einem Ausfall eines Moduls ersetzen lässt, ohne dass das gesamte Pack ausgetauscht werden muss oder mit einem leistungsschwachen Pack zu arbeiten ist. Schlecht konstruierte Module können ein Sicherheitsrisiko darstellen, das zu einem Fahrzeugbrand führen kann. Für OEMs ist es wichtig, ein Ökosystem-Management durchzusetzen, d.h. jedes Modul muss kryptografisch authentifiziert werden, um sicherzustellen, dass der Hersteller des Moduls vom OEM überprüft und genehmigt wurde, bevor es innerhalb des Packs zum Einsatz kommen darf. Ein Modul, das eine unzureichende Leistung erbringt, kann den Ruf der Marke schädigen und zu Umsatzeinbußen führen. Dies ist ein weiterer Grund, die Quelle des Modulherstellers kryptographisch zu verifizieren.

Was bedeutet es, ein Modul kryptografisch zu verifizieren? Hier spielen anwenderspezifische Signaturschlüssel eine Rolle, die Bausteine mit spezifischen x.509-Zertifikatsketten und einem eindeutigen Zertifikat auf Bauteilebene basierend auf einem eindeutigen ECC-Schlüsselpaar bereitstellen. Diese ICs werden in jedes Batteriemodul integriert. Wird ein Batteriemodul innerhalb des Packs ausgetauscht, fragt das Batteriemanagement-System (BMS), auch als Batterie-Gateway bezeichnet, das Modul nach seinem einzigartigen x.509-Zertifikat und überprüft die Signaturketten bis zu einem vertrauenswürdigen Stamm.

Nach der Signaturverifizierung wird dem zu signierenden Modul mit dem zugehörigen privaten Schlüssel eine Aufforderung vorgelegt, um die Kenntnis des Schlüssels zu belegen, ohne diesen auf den Bus zu übertragen – in einigen Fällen erfolgt dies über Funk. Die Anwendung auf Modulebene hört hier auf. Innerhalb des BMS benötigen OEMs oft eine komplexere Anwendung. Da das BMS/Gateway der Kommunikationspunkt zur Außenwelt ist, der regelmäßige Berichte über den Batteriezustand an die Cloud liefert, wird die Anwendung um sicheres Booten, sichere Firmware-Updates und Transport Layer Security (TLS) erweitert, um einen sicheren Kommunikationskanal mit der Cloud aufzubauen.

Alle besprochenen Sicherheitsimplementierungen erfordern einen sicheren Schlüsselspeicher, der nur mit echter hardwarebasierter Sicherheit erreichbar ist. Schlüssel aus Standard-Mikrocontrollern lassen sich leicht extrahieren – selbst aus jenen, die behaupten, „sichere Mikrocontroller“ zu sein. Dazu werden einige Standardangriffe durchgeführt, z.B. Mikroabtastung, Fehlerinjektion, elektromagnetische Seitenkanalangriffe, Temperatur-/Stromzyklus-/Versorgungsstörungen und Timing-Angriffe, um nur einige zu nennen.

Es kommt darauf an, den richtigen Baustein auszuwählen, um die Verschlüsselung durchzuführen und die Schlüssel vor solchen Angriffen zu schützen. Spezielle Sicherheits-ICs gibt es in einer Vielzahl von Architekturen und mit unterschiedlichen Bezeichnungen wie Hardware-Sicherheitsmodule (HSM) – sowohl auf dem Chip als auch extern: Secure Elements, sichere Speichersubsysteme, Key Vault, Smartcards etc. Diese Bausteine müssen einen Manipulationsschutz gegen die oben genannten Angriffe aufweisen, um die Schlüssel in ihrem sicheren Speicher zu schützen.

Wie kann ein Tier-1-Zulieferer oder OEM nun überprüfen, ob die implementierte Sicherheit gut genug ist? Der beste Weg für einen Anbieter von Secure-Element-ICs, deren Sicherheit zu beweisen, besteht darin, den Baustein einem Drittanbieter zur Durchführung einer Schwachstellenanalyse zu übergeben. Dieser sollte von einer vertrauenswürdigen Quelle wie dem nordamerikanischen National Institute of Standards of Technology (NIST), dem deutschen Bundesamt für Sicherheit in der Informationstechnik (BSI) oder der weltweit anerkannten Senior Officials Group Information Systems Security (SOGIS) akkreditiert sein. SOGIS-zertifizierte Einrichtungen verwenden ein weltweit anerkanntes Bewertungssystem für Schwachstellen der Joint Interpretation Library (JIL), das eine White-Box-Bewertung erfordert.

Der einreichende Chip-Hersteller muss dem Labor Unterlagen über das IC-Design (Datenfluss, Subsystem, Definition des Speicher-Mappings) zur Verfügung stellen, genauso wie die Hardware- und Firmware-Startsequenz, eine Beschreibung der Sicherheitsschutzmechanismen, ein vollständiges Datenblatt, Sicherheits- und Bootloader-Anleitungsdokumentation, den gesamten verfügbaren Code (RTL- und C-Ebene, Kryptobibliothek, FW), Algorithmus-Implementierungen, Programmier-Skripte, Kommunikationsprotokoll, Chip-Layout und Quellcode. Das Labor überprüft dann alle Unterlagen und entwirft einen Angriffsplan gegen die eingereichten Muster-ICs.

Das Bewertungssystem vergibt Punkte basierend auf der Dauer der Extraktion eines geheimen Schlüssels, dem erforderlichen Fachwissen (Hochschul-Absolvent bis hin zu mehreren Experten), der Kenntnis des Evaluierungsziels, dessen Zugang (wieviele Muster für einen erfolgreichen Angriff benötigt werden), der Komplexität und Kosten der Hacker-Ausrüstung sowie des einfachen Zugriffs auf die Muster. Die resultierenden JIL-Scores beginnen mit den Einstufungen keine Bewertung, dann folgen Basic, Enhanced Basic, Moderate und High als die beste erreichbare Punktzahl. Alles, was unter JIL High liegt, bedeutet, dass das Labor in der Lage war, den/die privaten Schlüssel aus dem Baustein zu extrahieren. Sicherheits-ICs wie der externe HSM CryptoAutomotive TrustAnchor100 (TA100) von Microchip, die die Bewertung JIL High erhalten haben, können Angriffen mehr als drei Monate lang standhalten. Daraufhin stuft das Labor den Baustein als „nicht angreifbar“ ein.

On-Chip oder Off-Chip?

On-Chip oder Off-Chip ist hier die Frage. On-Chip-Lösungen wie 32-Bit-Dual-Core-MCUs können ein teures Upgrade einer ECU der vorherigen Generation darstellen, die möglicherweise mit einer Standard-MCU gut bedient war, bevor echte Sicherheit von einem OEM vorgeschrieben wurde. Sie können auch zu erheblichen Verzögerungen bei der Markteinführung führen, da der Anwendungscode vollständig neu entwickelt werden muss. Es kann sehr riskant sein, die Entwicklung des Sicherheitscodes intern zu übernehmen – und es ist kostspielig, einen Drittanbieter zu bezahlen.

Außerdem ist es für einen Tier-1-Zulieferer schwierig, die Lösung aufgrund der unterschiedlichen Leistungs- und Peripherieanforderungen bei jedem Typ auf mehrere Arten von ECUs zu übertragen. Hier können externe HMS oder ergänzende Secure-Element-ICs den Aufwand für Sicherheits-Upgrades für Tier-1-Lieferanten erheblich reduzieren. Sie können neben einer Standard-MCU in ein bestehendes Design integriert oder in alle neuen Designs mit unterschiedlichen Host-MCU-Anforderungen integriert werden. Externe HSMs wie der TA100 werden mit allen Sicherheitscodes, Schlüsseln und Zertifikaten vorinstalliert geliefert, was die Markteinführung erheblich beschleunigt. Durch die zugehörige Crypto-Bibliothek, die MCU-unabhängig ist, lässt er sich leicht auf jede MCU übertragen. Das Risiko, die Zeit bis zur Markteinführung und die Gesamtkosten verringern sich und bieten Tier-1-Zulieferern einen flexiblen Weg, um vor den Mitbewerbern, die einen völlig neu entwickelten Weg einschlagen, Aufträge zu gewinnen. (na)