Die Möglichkeit, Software im Automobil über Mobilfunk im Feld zu ändern (Software-Update Over-the-Air, kurz SOTA) verspricht ein großes Sparpotenzial für die Automobilindustrie. Jedoch müssen hierbei ausreichende Sicherheitsmaßnahmen ergriffen werden. Aurix-Mikrocontroller und zusätzliche dedizierte Sicherheitscontroller wie der Optiga-TPM an zentralen Stellen unterstützen diese wichtige Absicherung. Neben konkreten Sicherheitsmaßnahmen müssen sich OEMs jedoch auch Gedanken machen, wie sie durch eine optimierte Netzwerkarchitektur und Speicherstrategie die Stillstandzeit des Fahrzeugs während des Updatevorgangs und somit den Einfluss auf den Fahrer möglichst minimieren.

Eck-Daten

Mit dem rasant zunehmenden Softwareumfang in Fahrzeugen werden auch erforderliche Softwareupdates immer häufiger. Anstatt neue Software oder Service-Packs in der Werkstatt zu überspielen, bietet die Übertragung über Mobilfunk direkt ins Fahrzeug signifikante Zeit- und Kostenersparnisse. Um hierbei auch den Sicherheitsaspekt ausreichend abzudecken, stellt Infineon entsprechende Mikrocontroller und Sicherheitsmodule zur Verfügung.

Die Einführung der E-Call-Funktionalität wird die Vernetzung von Automobilen weiter vorantreiben. IHS-Automotive geht bis 2020 von 152 Millionen vernetzten Fahrzeugen aus. Die Marktforscher von Gartner rechnen sogar mit etwa 250 Millionen. Die Motivation, um Mobilfunk-Verbindungen für SOTA zu nutzen, liegt in der signifikanten Kostenreduzierung bei Rückrufen, schnelleren Feature-Updates und einer höheren Kundenzufriedenheit.

OEMs stellen verschiedene Ansprüche an die SOTA-Implementierung. Grundsätzlich ist ein evolutionärer und kein revolutionärer Prozess bei der Anpassung des Fahrzeug-Netzwerkes gewünscht. Die nahtlose SOTA-Integration setzt voraus, das bestehende Implementierungen weiter genutzt und einzelne Steuereinheiten ausgetauscht werden können. Die Prozesse, wie man sie bisher von den OBD (On-Board-Diagnose)-Updates kennt, sollten möglichst beibehalten werden.

Eine besondere technische Herausforderung stellt die Implementierung von SOTA für elektrische Steuereinheiten (ECUs) außerhalb des Infotainment-Bereichs dar. Hier sind typischerweise Mikrocontroller mit Embedded-Flash im Einsatz, um die Echtzeit-Anwendungen im Automobil zu steuern. Auch der Anspruch an die Qualität und Sicherheit ist sicherzustellen. Die Safety des Fahrzeugs darf nicht durch mangelnde Security gefährdet werden.

Eine unzureichend abgesicherte SOTA-Implementierung, über die es potenziellen Angreifern ermöglicht wird, Manipulationen an Safety-kritischen Anwendungen des Fahrzeugs durchzuführen, kann die gesamte Sicherheit des Fahrzeugs und im schlimmsten Falls das Leben seiner Insassen gefährden. Um dies zu verhindern, bedarf es einer komplexen Security-Architektur, die durch die Verwendung von Zertifikaten und privaten Schlüsseln sowie kryptografischen Operationen unterstützt wird. Entsprechende Kryptographie basiert auf Standard-Algorithmen wie RSA, ECC, AES oder SHA. Sicherheitscontroller wie die Produkte der Aurix-Familie und der Optiga-TPM verfügen über derartige Sicherheitsfunktionen und -merkmale.

Aurix-Mikrocontroller mit integriertem HSM (Hardware-Security-Module) sind prädestiniert für eine sichere Authentifizierung und Verifizierung in SOTA-Applikationen

Aurix-Mikrocontroller mit integriertem HSM (Hardware-Security-Module) sind prädestiniert für eine sichere Authentifizierung und Verifizierung in SOTA-Applikationen Infineon

 

SOTA-Prozess

 

Wie sieht nun ein typischer SOTA-Flow aus? Über die Funkverbindung werden in der Telematik-Einheit die Authentifizierungs- und Verschlüsselungsdienste aktiviert und dann die übertragenen Daten mittels eines sicheren Protokolls empfangen bzw. entschlüsselt. Anschließend werden diese Service-Daten im Zentralspeicher des Fahrzeuges abgelegt. Nach Prüfung der OEM-Signatur und Verifizierung werden die Datenpakete für die Steuereinheiten entpackt. Jetzt beginnt der eigentliche Update-Vorgang mit der Programmierung, wobei die Service-Pakete in kleinen Blöcken zu den Steuereinheiten gesendet werden. Innerhalb der ECUs werden dann die Datenblöcke entschlüsselt, dekomprimiert und dann über den Secure-Flash-Bootloader neuer Code in den Flashspeicher geschrieben. Nach erfolgreicher Verifizierung des Updates wird dies zum Update-Server gemeldet. Am Ende des Update-Modus wird das Fahrzeug mit allen Steuereinheiten neu gebootet bzw. gestartet.

Der Secure-Flash-Bootloader ist das wesentliche Element für den SOTA-Prozess innerhalb der Steuerungseinheit. Dafür nutzt er Hardware-Security-Module (HSMs), um den Code zu schützen, sowie Schlüssel auf Basis von SHE- oder Evita-Standards. Der Secure-Flash-Bootloader sorgt für die entsprechende Kommunikation, startet den Update-Prozess und löscht die alte Software. Beim Laden der neuen Software (z.B. in Blöcken von 4 kB) entschlüsselt und überprüft er den Datenblock, dekomprimiert und überprüft die Signatur und schreibt letztendlich die Daten in den Flashspeicher. Zuletzt wir die Vollständigkeit überprüft und die Ausführung bestätigt.

All diese Aufgaben werden beispielsweise vom HSM im Aurix-Mikrocontroller (Bild 1) ausgeführt: Sicheres Booten, Authentifizierung, Ent- und Verschlüsselung, Schlüssel-Management und Integritätsüberprüfung. Die Flash-Autorisierung verhindert unerlaubte Schreib- und Lesezugriffe auf den Flashspeicher. Dafür ist ein 256-bit-Password erforderlich. Der Flash-Zugriff wird vom HSM nur nach erfolgreicher Authentifizierung des zentralen Gateway und nach Senden eines entsprechenden Programmierbefehls erlaubt.

 

SOTA-ECU-Struktur

Wesentliche Funktionsblöcke für eine SOTA-Implementierung: Telematik-Einheit, zentraler Gateway und Ziel-ECU

Wesentliche Funktionsblöcke für eine SOTA-Implementierung: Telematik-Einheit, zentraler Gateway und Ziel-ECU Infineon

Die Fahrzeug-Architektur für SOTA kann prinzipiell in drei ECU-Blöcke gegliedert werden, in denen unterschiedliche Security-Controller unterschiedliche Sicherheitsfunktionen übernehmen: Telematik-Steuergerät, zentrales Gateway und Ziel-Steuereinheit (Bild 2).

Die Telematik-Einheit stellt über ihre Mobilfunkschnittstelle eine Verbindung zum OEM-Server her und führt die Service-Authentifizierung aus. Für diese kritische Authentifizierungsfunktion wird aus Security-Gründen die Implementierung eines dedizierten Sicherheitscontrollers, ein Optiga-TPM (Trusted Platform Module), empfohlen. Ein Mikrocontroller der Aurix-Familie wird üblicherweise neben dem eigentlichen Applikationscontroller für die gesicherte Verbindung zum Fahrzeugnetzwerk genutzt.

Im zentralen Gateway unterstützt ein Aurix-Controller die Verifikation und Zwischenspeicherung der empfangenen Software. In der Ziel-ECU erfolgt nach Initialisierung durch den Fahrer das eigentliche Update. Dazu wird das Datenpaket aus dem Speicher in die Ziel-ECU geleitet, dort entschlüsselt, noch einmal verifiziert und schließlich „geflasht“. All diese sicherheitsrelevanten Funktionen werden von Aurix-Controllern unterstützt.

 

Sichere Authentifizierung und Verifizierung

 

Der Optiga-TPM (Bild 3) ist ein zertifizierter Sicherheits-Controller, der speziell für kritische Authentifizierungsfunktionen genutzt werden kann. Er sorgt dafür, dass nur autorisierte Instanzen Daten an das Fahrzeug schicken können.

Sicherheitscontroller der Optiga-TPM-Familie ermöglichen zusammen mit Aurix-Mikrocontrollern eine geschützte SOTA-Implementierung

Sicherheitscontroller der Optiga-TPM-Familie ermöglichen zusammen mit Aurix-Mikrocontrollern eine geschützte SOTA-Implementierung Infineon

Das TPM führt alle Verschlüsselungs-Algorithmen für die Authentifizierung aus. Dafür speichert es langfristig genutzte Zertifikate und entsprechende private Schlüssel in einer geschützten Umgebung. TPM 2.0 unterstützt Algorithmen wie ECC, RSA, AES oder SHA 256. Das TPM kann kryptographisch mit dem Applikationsprozessor verknüpft werden. Der Schlüsselspeicher des TPM ist skalierbar und kann sicher auf den externen Speicher des Applikationsprozessors geladen werden. Damit können OEMs weitere Authentifizierungs-Zertifikate abspeichern.

Typische Cyber-Angriffe manipulieren ein System in der Art und Weise, das dieses nicht-spezifizierte Operationen ausführt. Um dies zu verhindern, werden Systeme oftmals in verschiedene, voneinander isolierte Sicherheits-Domains unterteilt. Ein Beispiel ist das TPM, das die asymmetrischen Schlüssel in einer separaten, geschützten Umgebung ablegt. Aber auch Mikrocontroller verfügen über isolierte Security-Bereiche. So kann das HSM in den Aurix-Mikrocontrollern Security-Funktionen von der Applikations-Domain isolieren. Ein erster wesentlicher Schritt ist eine Unversehrtheitsprüfung des Programmspeichers der beteiligten Mikrocontroller zu Beginn des Fahrzyklus mittels Secure-Boot (SHE oder HSM überprüfen dabei den Speicherinhalt anhand einer kryptographischen Prüfsumme).

Die AURIX- Mikrocontrollerfamilie mit ihrem integrierten HSM übernimmt außerdem die wichtige Verifikation empfangener Software. Dabei profitiert die Verifizierung von den leistungsfähigen Verschlüsselungsbeschleunigern und den schnellen Kommunikationsbussen des HSM. Diese Verifizierung wird durch die Gateway-MCU mittels HSM durchgeführt. Da die Firmware-Verifizierung nur öffentliche Zertifikate nutzt, sind die Security-Anforderungen geringer als beim Authentifizierungsprozess.

 

Maximale Verfügbarkeit erhöht Kundenakzeptanz

 

Neben dem Thema Sicherheit bei der SOTA-Integration ist für Automobilhersteller von entscheidender Bedeutung, dass die bestehende Systemarchitektur des Automobils möglichst minimal beeinflusst und eine maximale Verfügbarkeit gewährleistet wird, d.h. Minimierung der Updatezeit, in der das Fahrzeug stillstehen muss.

Bisher wird die Neuprogrammierung einer ECU (oder auch des gesamten Fahrzeugs) üblicherweise in einer Werkstatt ausgeführt. Derartige Updates nutzen ein Diagnose-Tool, das an den OBD (On-Board-Diagnosis)-Stecker angeschlossen wird. Das Diagnose-Tool steuert den kompletten Update-Prozess, insbesondere das Herunterladen der neuen Software bzw. des Service-Packs, die Distribution zur Ziel-ECU und die finale Verifizierung. OEMs sind bestrebt, auch für SOTA möglichst nah an diesem Mechanismus zu arbeiten. Für SOTA ist es daher entscheidend, die Funktionalität des Diagnose-Tools auf eine zentrale Stelle in der Boardnetz-Architektur zu übertragen und mit den erforderlichen Funktionen für den zusätzlichen SOTA-Ablauf zu versehen. Diese Funktionen werden üblicherweise innerhalb der Gateway-ECU ausgeführt, in der ein zentraler Speicher das neue Softwarepaket nach dem Download vom OEM-Server zwischenspeichert.

Da die neue Software vom zentralen Speicher des Gateways zur Ziel-ECU gelangen muss, muss die Netzwerk-Topologie beachtet werden, die von OEM zu OEM unterschiedlich ist. Grundsätzlich kann zwischen verschiedenen Ansätzen unterschieden werden.

Vergleich des Datentransfers für verschiedene Bussysteme

Vergleich des Datentransfers für verschiedene Bussysteme Infineon

Beim sogenannten „klassischen Verfahren“ wird für das Update einer individuellen ECU das entsprechende neue Softwarepaket vom Zentralspeicher über das Board-Netzwerk in den Embedded-Flash-Speicher des Mikrocontrollers der Ziel-ECU geladen – und zwar in einem Schritt. Hierbei sind keine Hardware-Änderungen seitens der ECUs erforderlich. Die wesentliche Einschränkung liegt bei den Bus-Geschwindigkeiten und damit in der Dauer für die Updates. Bei einem Service-Paket von 4 MByte benötigt das Update für eine einzelne ECU über den CAN-Bus fast fünf Minuten und bei 20 ECUs kann das Fahrzeug über 1,5 Stunden nicht genutzt werden (Tabelle 1).

Ein optimierter Ansatz sieht einen zusätzlichen externeren Speicher auf ECU-Ebene vor, in den während des Fahrzeugbetriebs im Hintergrund das neue Service-Pack geladen wird und dort auf den eigentlichen Updateprozess wartet. Diese Methode nutzt die Tatsache, dass moderne Mikrocontroller wie die Aurix-Familie ihren Programm-Flashspeicher sehr schnell löschen und neu programmieren können. So können 4 MByte innerhalb von 8 s gelöscht und aus dem externen lokalen Speicher über die SPI-Schnittstelle neu programmiert werden. Die wesentlichen Vorteile dieses Ansatzes sind ein minimaler Eingriff in das bestehende System-Design, überschaubare Zusatzkosten und geringe Abmessungen für das zusätzliche Speicherelement.

 

Fazit und Ausblick

 

SOTA eröffnet eine signifikante Kostenersparnis, erhöht die Nutzerfreundlichkeit und eröffnet neue Geschäftsmodelle. Allerdings gilt es durch entsprechende Maßnahmen die hohen Security-Anforderungen zu erfüllen. Dafür stehen mit den Aurix-Mikrocontrollern und den Optiga-TPM-Chips entsprechende Hardware-Lösungen zur Verfügung. Eine Architektur auf Basis dieser Komponenten ermöglicht eine sichere Authentifizierung hin zum OEM-Backend und eine geschützte Datenübertragung mit Verschlüsselung vom zentralen Speicher.

Die neueste Aurix-Generation (TC3XX) mit neuem HSM macht die On-Board-Kommunikation und SOTA-Applikationen noch sicherer

Die neueste Aurix-Generation (TC3XX) mit neuem HSM macht die On-Board-Kommunikation und SOTA-Applikationen noch sicherer Infineon

Bei der neuen Aurix-Generation TC3xx (Bild 4) wurde das Hardware-Security-Modul nochmals erweitert. Das neue HSM macht die On-Board-Kommunikation noch sicherer und erschwert Hardware-Manipulationen. Es integriert neue Funktionen zur Unterstützung asymmetrischer Verschlüsselungsmechanismen gemäß den Evita-„high“-Anforderungen. Damit unterstützt der Aurix insbesondere SOTA-Applikation und hilft, Software-Hijacking zu verhindern. Als Hostcontroller in Gateway- und Telematikanwendungen unterstützen die Aurix TC3xx die neuesten Kommunikationsschnittstellen. Eine zusätzliche E-MMC-Schnittstelle für externe Flash-Speicher ermöglicht die lokale Datenspeicherung für SOTA-Architekturen.