Flexibilität vs. Security vs. Ressourcen Trusted Execution Environments in Automotive-Echtzeitsystemen

Echtzeitumgebungen unterliegen schon immer hohen Anforderungen an eine effiziente und ressourcenschonende Umsetzung, doch im Software Defined Vehicle kommen zusätzliche Ansprüche hinzu. Trusted Execution Environments (TEEs) könnten hier eine Lösung darstellen.

„Electronic control units and software of increasing complexity have become essential to the operation of road vehicles in recent years. This software is often updated to in-crease functionality and maintain the safety and cybersecurity of road vehicles“ [1]. Wenn selbst eine ISO-Norm das bereits im Einleitungskapitel feststellt, dann muss es von Bedeutung sein. Seien es neue gesetzliche Regularien zu Datenschutz (z.B. DSGVO) oder Softwareupdates (z.B. ISO 24089:2023-02), funktionale Anforderungen hinsichtlich Online-Anbindung oder Kundenerlebnis oder auch technologische Herausforderungen, wie zum Beispiel das Aufkommen von Quantencomputern in absehbarer Zeit. Diese und weitere Vorgaben führen zu konkreten technischen Aufgabenstellungen, wie die Absicherung von vertraulichen Daten, Verschlüsselung von Kommunikationswegen oder Updatefähigkeit von Security-relevanten Programmteilen. Trusted Execution Environments können Lösungen anbieten für einige dieser Probleme. Durch die Isolierung besonders schützenswerter Daten und Programmteile bieten sie Schutz gegen Manipulation und unberechtigten Zugriff und tragen somit einen wesentlichen Anteil zum Erreichen der Schutzziele Vertraulichkeit und Integrität bei.

Aber nicht nur diese vermeintlich neuen Herausforderungen muss ein Steuergerät im Automobil erfüllen. Es gibt weitere Anforderungsbereiche, welche die Auswahl der Hardwarekomponenten, insbesondere der Microcontroller stark beeinflussen. Genannt seien hierbei auf jeden Fall die Safety, welche die Echtzeitfähigkeit vieler signifikanter Fahrzeugfunktion zwingend notwendig macht. Ferner steigt der Kostendruck, ins-besondere auf europäische Automobilhersteller, wodurch jede Komponente im Fahrzeug kostenoptimiert entwickelt und produziert werden muss. Beide Aspekte, sowie die Umweltanforderungen an ein Steuergerät im Automobil, schränken die Auswahl an geeigneten Microcontrollern ein. Es wird immer wichtiger die begrenzt vorhandenen Ressourcen der nutzbaren Hardware optimal zu nutzen, um technischen und regulatorischen Herausforderungen in der Zukunft entgegenzutreten.

Diese Arbeit untersucht aktuell verfügbare Alternativen von Trusted Execution Environments in echtzeitfähigen Automotive-Systemen. Weiterhin werden die neuen Anforderungen an Fahrzeuge betrachtet, die Bezug haben zu den Aufgaben einer TEE. Hier seien insbesondere die stetige Erweiterung der Funktionalität des bereits ausgelieferten Fahrzeuges (im Software Defined Vehicle), sowie die Kryptoagilität genannt. Nach diesen Betrachtungen soll ein Konzept vorgestellt werden, welches zukünftige Herausforderungen an TEEs angeht. Dieses Konzept zeigt einen Lösungsansatz auf, damit Fahrzeuge die heute entwickelt und morgen produziert werden, auch noch in Jahren safe und secure sind.

Trusted Execution Environment

Eine Trusted Execution Environment ist eine manipulationssichere Umgebung, die auf einem separierten Kernel aufgeführt wird. Sie garantiert die Authentizität, Vertraulichkeit und Integrität der Laufzeitzustände des ausgeführten Codes, sowie der persistent gespeicherten Daten. Durch die strenge Isolation von Speicher, eines eigenen Prozessorkerns und peripheren Hardwarekomponenten, können die in der TEE laufenden Security-relevanten Applikationen völlig unabhängig von der Hostumgebung ausgeführt werden. Cyberangriffe auf die Hostumgebung wirken sich aufgrund der strikten Separation nicht auf die TEE aus [2].

Hardware Security Module

Ein Hardware Security Module (HSM) ist in der Regel als isolierter Co-Prozessor in einem Mikrocontroller integriert und verfügt über eigene spezialisierte Module wie einen Zufallszahlengenerator, symmetrische Verschlüsselung, Hash-Module und asymmetrische Kryptographie (z.B. ECDSA) [3]. Es ist so konzipiert, dass es Sicherheitsfunktionen wie Secure Boot, Tuning-Schutz, Wegfahrsperre und Authentifizierung unterstützt. Die Firmware des HSM läuft unabhängig vom Host-System. Die Kommunikation mit diesem erfolgt über spezielle Schnittstellen, wobei das HSM selbst vor unautorisierten Zugriffen geschützt ist [4]. Der Co-Prozessor auf dem das HSM ausgeführt wird, ist in der Regel deutlich weniger performant als die Hauptprozessorkerne.

Entsprechend der EVITA (E-safety vehicle intrusion protected applications) können HSMs in drei Klassen eingeteilt werden – small, medium und full. Die folgende Tabelle gibt einen Überblick über die Funktionalitäten, welche durch die Klassifizierung den HSM-Abstufungen zugeordnet werden. Die Unterschiede in Komplexität und Funktionalität dienen dabei der Skalierbarkeit und Kostenoptimierung bei der Entwicklung und beim Einsatz von HSMs [5].

Trusted Platform Module

Das diskrete Trusted Platform Module (TPM) ist ein separater Chip, der auf dem Steuergerät (ECU) verbaut wird und über ein externes Bussystem wie SPI oder I²C mit dem Microcontroller verbunden ist. Der Einbau des TPM ist optional, was dann vorteilhaft ist, wenn z.B. eine Bestückvariante notwendig ist, um Handelsbeschränkungen für bestimmte Features einzuhalten. Im Vergleich zum Hardware Security Module (HSM) bietet das TPM einen reduzierten Funktionsumfang. Es ermöglicht die Erzeugung und Speicherung von Schlüsseln und verfügt über einen echten Zufallszahlengenerator (True Random Number Generator, TRNG) sowie einen sicheren Speicher [6]. Das TPM kann kryptografische Algorithmen berechnen, ist jedoch durch die langsamere Anbindung über ein externes Bussystem nicht so performant nutzbar wie ein HSM. Ein zusätzlicher Nachteil der externen Schnittstelle ist, dass diese leichter angreifbar ist als ein Interface innerhalb des Mikrocontrollers.

ARM TrustZone

Die ARM TrustZone Technologie ist ein Hardwarekonzept für ARM-basierte Mikrocontroller, die eine sichere und nicht-sichere Ausführung von Software ermöglicht. Dabei werden zwei separate Registersets und Stacks verwendet, um die sichere und nicht-sichere Verarbeitung zu trennen. TrustZone ist ein optionales Feature, das in ausgewählten Derivaten wie dem Cortex-M33 verfügbar ist. Es ermöglicht die Trennung von Speicher und Peripheriegeräten in sichere und nicht-sichere Enklaven. Die Verbindung zwischen diesen Enklaven erfolgt über einen Monitor, der eine kontrollierte Kommunikation zwischen den sicheren und nicht-sicheren Bereichen ermöglicht [2] [7]. Die ARM TrustZone ist, wie der Name schon sagt nur auf ARM-Prozessoren verfügbar, bietet dort allerdings eine gute Skalierbarkeit der sicheren Laufzeitumgebung.

Innovate Your Software – for a Smarter Future

Deutschlands Leitkongress der Embedded-Softwarebranche

Das Programm des ESE Kongress umfasst 96 Vorträge, 21 Seminare und 3 Keynotes. Seien Sie dabei, wenn sich die Embedded-Software-Community trifft, und nutzen Sie Diskussionen und Expertengespräche für einen ergiebigen Wissenstransfer und erfolgreiches Networken. Während der vier Kongresstage erwartet Sie zudem eine große Fachausstellung mit den führenden Firmen der Branche. Erfahren Sie alles über die neuesten Trends, Herausforderungen und Lösungen im Embedded Software Engineering, von KI, Safety und Security bis hin zu Management und Innovation.

Jetzt mehr erfahren und anmelden!

Klassische Anforderungen an die TEE im Automobil

TEEs in Echtzeitsteuergeräten erfüllen schon heute eine Vielzahl an Anforderungen, welche im Automotive-Bereich umgesetzt werden müssen. Die folgende Tabelle gibt eine Übersicht über diese „klassischen“ Funktionen.

Anforderungen im Software Defined Vehicle

Zukünftige Fahrzeugentwicklungen legen den Fokus immer stärker auf in Software umgesetzte Funktionalitäten, um das Kundenerlebnis zu definieren. Eine Voraussetzung dafür ist die Update-Fähigkeit von Software selbst im bereits ausgelieferten Fahrzeug. Es können sowohl neue Funktionalitäten im Feld eingespielt werden als auch Updates, um zum Beispiel Fehler in der ausgelieferten Software zu beheben.

Damit daraus kein Nachteil für den Kunden entsteht (häufigere Werkstattbesuche), wird die Software Over-the-air (OTA) aktualisiert, das heißt in einem im Feld befindlichen Fahrzeug. Diese Art des Software-Updates birgt neue Sicherheitsrisiken, welche durch geeignete Security-Funktionen (Secure Update) abgesichert werden müssen.

Kryptoagilität

Expertenschätzungen zu Folge können bereits in zehn Jahren leistungsfähige Quantencomputer verfügbar sein, die in der Lage sind aktuelle kryptographische Verfahren zu brechen. Aus diesem Grund hat das NIST im Jahr 2017 einen Standardisierungsprozess gestartet, aus dem Quantencomputer-sichere kryptographische Methoden (Post-Quantum Cryptography – PQC) hervorgehen sollen. In einem langwierigen mehrstufigen Auswahlverfahren wurden bisher fünf solcher Algorithmen selektiert und vier da-von bereits standardisiert [10] [11]. Ob es weitere Stufen im Auswahlverfahren gibt und ob die standardisierten Methoden der Bedrohung durch Quantencomputern dauerhaft standhalten, ist aktuell nicht absehbar.

Fahrzeuge, die heute entwickelt oder ausgeliefert werden, sind auch in 10 Jahren noch in Betrieb und somit potenziell durch Quantencomputer angreifbar. Nicht vorhandene Hardwareunterstützung für und fehlende Erfahrung mit PQC-Verfahren, sowie die nicht vorhersehbaren Fortschritte in der Entwicklung der Quantencomputer priorisieren eine bisher in der Automobilindustrie kaum wahrgenommene Anforderung – Kryptoagilität. Diese fordert es: „sollte vor allem darauf geachtet werden, die kryptografischen Mechanismen möglichst flexibel zu gestalten, um auf Entwicklungen reagieren, kommende Empfehlungen und Standards umsetzen und möglicherweise in Zukunft Algorithmen, die nicht mehr das gewünschte Sicherheitsniveau garantieren, austauschen zu können“ [12].

Die bereits 2021 vom Bundesamt für Sicherheit in der Informationstechnik (BSI) geforderte Eigenschaft soll „unabhängig von der Entwicklung von Quantencomputern – zum Designkriterium für neue Produkte werden.“ [12]. Kryptoagilität im Fahrzeug kann mit vertretbarem Wartungsaufwand nur in Software umgesetzt werden, da ein massenhafter Austausch von Hardware im Automobilmarkt kostenintensiv und unbedingt zu vermeiden ist.

Ressourcenbedarf

Die bisher beschriebenen zukünftigen Anforderungen (Secure Update, Kryptoagilität) und weitere Aspekte (z.B. Datenschutz nach DSGVO) erhöhen den Ressourcenbedarf für Security-relevante Funktionalitäten im Fahrzeug. Allein die Softwareumsetzung von PQC-Algorithmen ist in aktuellen hardwarebasierten TEEs kaum denkbar, da die Rechenleistung und der Speicherbedarf gegenüber bisherigen kryptographischen Algorithmen enorm gestiegen sind [13]. Aber nicht nur der absolute Bedarf an Ressourcen, sondern auch deren Skalierbarkeit wird zukünftig noch wichtiger werden. Wenn in einem Fahrzeug neue Funktionen eingespielt werden und die TEE aufgrund limitierter Ressourcen an ihre Leistungsgrenze kommt, muss diese Grenze flexibel sein.

Firmware Security Module – ein Konzept für die Zukunft

Als Alternative zu den bereits vorgestellten Umsetzungen von TEEs soll nun ein Konzept betrachtet werden, welches sowohl den klassischen Anforderungskatalog umsetzt als auch den neuen Herausforderungen begegnet. Das Firmware Security Module (FSM) implementiert sämtliche notwendigen Security-relevanten Funktionalitäten, die im Steuergerät benötigt werden. Diese sind durch die modulare Architektur skalierbar und der Funktionsumfang des FSM kann somit an die konkreten Bedürfnisse eines speziellen Systems angepasst werden.

Die Kommunikation des FSM zum Host System läuft über das Bridge Module. Hier werden Anfragen an das FSM entgegengenommen, geprüft und an den Activity Manager weitergegeben. Um Rückschlüsse auf interne Zustände des FSMs zu verhindern, sorgt das Bridge Module zusätzlich dafür, dass die Antwortzeiten auf Anfragen immer konstant sind [14] [15].

Die reine Softwareimplementierung löst die meisten Abhängigkeiten zur Hardware auf und ermöglicht es somit, das FSM auf einem leistungsstarken CPU-Kern eines Mehrkernsystems ausführen zu lassen (Bild). Dadurch stehen dem FSM deutlich mehr Rechenleistung und Speicherplatz zur Verfügung. Durch die in Software umgesetzte Abgrenzung zur unsicheren Umgebung können die Ressourcen für das FSM auch weiter skaliert werden, indem zum Beispiel ein zweiter CPU-Kern oder mehr Speicher dafür allokiert wird. Die gesteigerte Unabhängigkeit von Hardwarekomponenten bringt jedoch nicht nur Vorteile. Einerseits muss der allokierte Speicher beim Systemstart mittels einer Memory Protection Unit (MPU) geschützt werden, daher muss das FSM zwingend auf dem zuerst startenden CPU-Kern (meist Core 0) ausgeführt werden. Weiterhin können nützliche Hardwarekomponenten für klassische Kryptographie, die meist in der HSM liegen, nicht genutzt werden, wie zum Beispiel Hardwarebeschleuniger für kryptographische Algorithmen oder ein echter Zufallszahlengenerator.

In der folgenden Tabelle wird eine Übersicht über die Stärken und Schwächen der vorgestellten TEE Varianten dargestellt. Daraus wird klar ersichtlich, dass das FSM genau dort Vorteile bietet, wo die Hardware-gebundenen TEEs an ihre Grenzen kommen. Aber auch diese haben weiterhin ihre Berechtigung und sind bei klassischer Kryptographie und Features die mit Hardwareunterstützung performanter laufen, deutlich überlegen.

In diesem Artikel wurden die zukünftigen neuen Herausforderungen für Trusted Execution Environments vorgestellt und untersucht, wie aktuelle Hardwaregebundene TEEs damit umgehen können. Als Alternative wird das Firmware Security Module präsentiert, welches denselben Anforderungskatalog in Software umsetzt und somit einen ganz anderen Ansatz wählt. Hierbei wird deutlich mehr Priorität auf Skalierbarkeit von Ressourcen, Hardwareunabhängigkeit und Updatefähigkeit gelegt. Dies sind Eigenschaften, die TEEs aufgrund der zu erwartenden Änderungen in Technologie, Gesetzgebung und Entwicklungsschwerpunkten im Automobil dringend erfüllen müssen. Die Schwächen des FSMs, wie zum Beispiel das Fehlen eines Zufallszahlengenerators mit echter Entropie, zeigen aber auch, dass nicht vollständig auf den Einsatz von Hardwareunterstützung verzichtet werden kann. Möglich wäre hier ein kombinierter Einsatz vom FSM und klassischer TEE. (sg)

Literatur- und Quellenverzeichnis

[1] ISO - International organization for standardization, "ISO 24089:2023-02".

[2] M. Sabt, M. Achemlal and A. Bouabdallah, "Trusted Execution Environment: What It is, and What It is Not," in 14th IEEE International Conference on Trust, Security and Privacy in Computing and Communications, Helsinki, Finland, 2015.

[3] Vector Informatik GmbH, "Introducing Hardware Security Modules to Embedded Systems," in Vector E-Mobility Engineering Day, 2017.

[4] A. Hattendorf, A. Raabe and A. Knoll, "Shared memory protection for spatial separation in multicore architectures," in 7th IEEE International Symposium on Industrial Embedded Systems (SIES’12), Karlsruhe, 2012.

[5] O. Henniger, A. Ruddle, H. Seudié, B. Weyl, M. Wolf and T. Wollinger, "Securing Vehicular On-Board IT Systems: The EVITA Project," in Joint VDI/VW Automotive Security Conference, Ingolstadt, 2009.

[6] "Trusted Platform Module (TPM)," Trusted Computing Group, [Online]. Available: https://trustedcomputinggroup.org/work-groups/trusted-platform-module/. [Accessed 10 2025].

[7] ARM Limited, "ARM Security Technology Building a Secure System using TrustZone Technology," [Online]. Available: https://developer.arm.com/documentation/PRD29-GENC-009492/latest/. [Accessed 10 2025].

[8] C. Pott, P. Jungklass, D. J. Csejka, T. Eisenbarth and M. Siebert, "Firmware Security Module," Journal of Hardware and Systems Security, 2021.

[9] M. Wolf and T. Gendrullis, "Design, Implementation, and Evaluation of a Vehicular Hardware Security Module," in Information Security and Cryptology - ICISC 2011, 2011.

[10] P. Jungklass, M. Manthe and D. J. Csejka, "Post-Quantum-Kryptographie auf eingebetteten Steuergeräten," in Embedded Software Engineering Kongress, Sindelfingen, 2024.

[11] P. Jungklass, C.-P. Stöber-Schmidt, R. Barg, H. Hansen and M. Siebert, "Post-Quantum Cryptography on Embedded ECUs," in 2024 JSAE Annual Congress (Spring), 2024.

[12] (BSI), Bundesamt für Sicherheit in der Informationstechnik, "Kryptografie quantensicher gestalten," Dezember 2021. [Online]. Available: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Broschueren/Kryptografie-quantensicher-gestalten.pdf?__blob=publicationFile&v=6.

[13] P. Jungklass, Beitrag zur Optimierung der statischen Speicherverwaltung in eingebetteten Mehrkernsystemen mit einer harten Echtzeitanforderung, Lübeck: Universität zu Lübeck, 2025.

[14] P. Jungklass, C.-P. Stöber-Schmidt, M. Siebert, J. Rummel and T. Nigoro, "Firmware Security Module," in 2025 JSAE Annual Congress (Spring), 2025.

[15] P. Jungklass and R. Barg, "Firmware Security Module - Sicherheit über die gesamte Lebensdauer?," in Embedded Software Engineering Kongress, Sindelfingen, 2023.

[16] P. Jungklass, "Firmware Security Module," in 4th Charter of Trust Meetup Braunschweig, Braunschweig, 2024.

Dieser Beitrag stammt aus dem Tagungsband zum ESE-Kongress 2025.

* Dipl.-Ing. (FH), M. Sc. Martin Manthe studierte an der Hochschule Stralsund Informatik und arbeitet seit vielen Jahren als Entwicklungsingenieur im Embedded Software Bereich. Zum Start seiner beruflichen Tätigkeit entwickelte er Basissoftwarekomponenten für verschiedene Steuergeräte diverser OEMs im Automotive-Sektor. Nach einer längeren Entwicklertätigkeit im Luftfahrtbereich beschäftigt er sich aktuell mit verschiedenen Security-relevanten Anwendungen (wieder im Automotive-Bereich).

(ID:50915719)