Sichere Designprinzipien hinter Trusted Applications im Automotive-Bereich

Wenn wir auf den Begriff Trusted Application stoßen, denken die meisten von uns zunächst an Software, die tief innerhalb einer Trusted Execution Environment (TEE) ausgeführt wird, isoliert, verschlüsselt und geschützt.

Doch das ist nur die halbe Wahrheit.

Das „Vertrauen“ in eine Trusted Application entsteht nicht automatisch. Es wird durch Architekturentscheidungen, disziplinierte Softwareentwicklung und das Verhalten des Gesamtsystems geschaffen.

In modernen Fahrzeugen ist diese Unterscheidung wichtiger denn je. Heutige Fahrzeuge verfügen über zahlreiche Steuergeräte (ECUs), die unterschiedliche sicherheitskritische Funktionen ausführen. In diesem komplexen Netzwerk ist eine Trusted Application weit mehr als nur eine weitere Sicherheitskomponente. Sie stellt sicher, dass Befehle, kryptografische Schlüssel und Updates exakt wie vorgesehen verarbeitet werden.

Die Ironie dabei: Selbst Anwendungen innerhalb einer TEE sind nicht automatisch vertrauenswürdig. Das Bestehen von Compliance-Prüfungen garantiert keine Integrität, wenn das zugrunde liegende Design Schwachstellen aufweist oder falsche Annahmen getroffen werden.

Genau hier kommen technische Designprinzipien ins Spiel. Sie sorgen dafür, dass Vertrauen kein Label, sondern das Ergebnis eines durchdachten Sicherheitsdesigns ist.

In diesem Artikel betrachten wir daher nicht Schlagworte, sondern die grundlegenden Faktoren, die eine Trusted Application im Kontext moderner Fahrzeuge tatsächlich vertrauenswürdig machen.

Trusted Applications: Die Grundlage verstehen

Eine Trusted Application (TA) ist eine spezialisierte Softwarekomponente, die innerhalb einer sicheren, isolierten Umgebung ausgeführt wird, der sogenannten Trusted Execution Environment (TEE). Hauptaufgabe einer TA ist die Verarbeitung sensibler Funktionen wie Schlüsselmanagement, Secure-Boot-Validierung und Authentifizierung, ohne den Schwachstellen des normalen Betriebssystems ausgesetzt zu sein.

Innerhalb der TEE fungiert die Trusted Application als sicherer Kern sensibler Prozesse. Sie kommuniziert zwar mit der Client Application (CA) in der Rich Execution Environment (REE), jedoch ausschließlich unter strengen Zugriffskontrollen.

Vereinfacht betrachtet handelt es sich um einen besonders geschützten Bereich, der sensible Daten überwacht und verhindert, dass diese den geschützten Sicherheitsbereich verlassen.

Dabei stellen sich häufig zwei Fragen:

• Warum werden Trusted Applications benötigt?
• Worin unterscheiden sie sich von herkömmlichen Anwendungen?

Normale Anwendungen innerhalb der REE werden primär für Funktionalität und Performance entwickelt. Sie sind flexibel, funktionsreich und interagieren mit zahlreichen Betriebssystemdiensten und -ebenen.

Eine Trusted Application hingegen wird auf Vertrauenswürdigkeit und Sicherheit ausgelegt. Ihr Funktionsumfang ist bewusst begrenzt und folgt konsequent dem Prinzip der geringsten Privilegien. Ihr Wert ergibt sich nicht daraus, was sie tun kann, sondern aus dem, was sie bewusst nicht erlaubt.

Warum „Trusted“ nicht automatisch „sicher“ bedeutet

Ein weit verbreitetes Missverständnis lautet: „Trusted Applications sind von Natur aus sicher.“

Das ist jedoch nicht der Fall. Allein die Ausführung innerhalb einer TEE garantiert keine Sicherheit. Verfügt eine Anwendung über fehlerhafte Logik, mangelhafte Zugriffskontrollen oder unsichere Datenverarbeitung, kann die TEE lediglich die kompromittierte Anwendung isolieren.

Anders ausgedrückt: Die TEE schützt die Umgebung, sie validiert jedoch nicht das Design der Anwendung. Echte Sicherheit entsteht durch die Art und Weise, wie die Trusted Application entworfen und entwickelt wird.

Der Aufbau von Vertrauen beginnt deshalb bereits in der Designphase, mit Secure Coding, klarer Bedrohungsmodellierung und einer disziplinierten Definition der Interaktionen mit externen Systemen.

Erst wenn sämtliche Ebenen von Design bis Deployment diesen Prinzipien folgen, wird eine „Trusted Application“ ihrem Namen tatsächlich gerecht.

Die zentralen sicheren Designprinzipien für Automotive Trusted Applications

Designprinzipien schließen die Lücke zwischen einer „sicheren Umgebung“ und einem „sicheren Design“. Sie stellen sicher, dass eine Trusted Application nicht nur in einer sicheren Umgebung existiert, sondern sich über ihren gesamten Lebenszyklus hinweg sicher verhält.

Im modernen Automotive-Ökosystem müssen Trusted Applications deutlich mehr leisten als sichere Datenspeicherung oder isolierte Ausführung. Sie müssen vorhersehbares Verhalten, überprüfbare Integrität und minimale Angriffsflächen gewährleisten. Fundament dafür sind die folgenden Designprinzipien.

1. Principle of Least Privilege: Minimierung der Angriffsfläche

Die Funktionsweise von Trusted Applications basiert wesentlich auf dem Prinzip der geringsten Privilegien (Principle of Least Privilege, PoLP). Danach sollte eine Komponente ausschließlich die Rechte erhalten, die sie für ihre Aufgabe zwingend benötigt.

In der Praxis bedeutet dies eine klare Definition aller Schnittstellen, den Zugriff ausschließlich auf notwendige Ressourcen sowie die Validierung aller eingehenden Anfragen. Nichts wird implizit als sicher betrachtet, alles wird kontrolliert.

Im Kontext von Software Defined Vehicles (SDVs) interagieren einzelne ECUs mit zahlreichen Systemen. Ein zu großer Funktionsumfang einer Trusted Application kann:

• zusätzliche Angriffsvektoren eröffnen,
• die Systemstabilität beeinträchtigen,
• Audits und Verifizierungen erschweren.

Durch die konsequente Umsetzung des PoLP wird die Angriffsfläche reduziert. Weniger Schnittstellen, weniger Abhängigkeiten und ein begrenzter Zugriff auf untrusted Inputs erhöhen die Sicherheit erheblich.

Selbst wenn andere Systemkomponenten kompromittiert werden, kann die Trusted Application ihre definierten Sicherheitsgrenzen weiterhin durchsetzen und so die Integrität der Sicherheitsarchitektur des Fahrzeugs schützen.

2. Sichere Schnittstellen: Vertrauensgrenzen schaffen

Trusted Applications arbeiten nicht isoliert. Sie tauschen kontinuierlich Informationen mit der REE, anderen ECUs und teilweise auch externen Diensten aus. Jede dieser Interaktionen stellt einen potenziellen Expositionspunkt dar und erfordert daher sichere Schnittstellen.

Eine sichere Schnittstelle ist weit mehr als nur eine API oder ein Kommunikationskanal. Sie definiert als Vertrauensgrenze, welche Daten empfangen werden dürfen, wie Anfragen verarbeitet werden und welche Informationen zurückgegeben werden. Jede Eingabe wird validiert, jede Anfrage authentifiziert und jede Ausgabe kontrolliert.

Besonders im Automotive-Bereich sind solche Vertrauensgrenzen essenziell.

Ein Beispiel: Eine OTA-Update-TA empfängt Firmware-Pakete, überprüft deren Authentizität und installiert Updates. Ist die Schnittstelle zwischen REE und TA unzureichend definiert oder validiert, können bösartige Payloads oder unerwartete Befehle Sicherheitskontrollen umgehen.

Gut gestaltete Schnittstellen verbessern außerdem die Vorhersagbarkeit und Überprüfbarkeit des Verhaltens einer Trusted Application. Dadurch werden Audits sowie Sicherheitstests deutlich effizienter.

3. Complete Mediation und Input Validation

Selbst bei klar definierten Privilegien und sicheren Schnittstellen darf Vertrauen niemals dauerhaft vorausgesetzt werden. Es muss kontinuierlich überprüft werden. Genau dies gewährleistet das Prinzip der Complete Mediation.

Jeder Zugriff auf Daten, Speicher oder Services wird validiert. Nur weil eine Anfrage einmal genehmigt wurde, bleibt sie nicht automatisch vertrauenswürdig. Die Trusted Application muss Identität, Kontext und Berechtigungen bei jeder Transaktion erneut überprüfen.

Ein Beispiel ist eine Trusted Application, die Firmware im Rahmen eines OTA-Updates entschlüsselt. Ohne Complete Mediation könnte ein zuvor authentifizierter Prozess seine Autorisierung missbrauchen, um manipulierte Dateien einzuschleusen. Die kontinuierliche Validierung verhindert solche Angriffe.

In Kombination mit einer konsequenten Input Validation entsteht ein besonders robuster Schutzmechanismus. Sämtliche Eingaben werden hinsichtlich Integrität, Struktur und Herkunft geprüft. Daten, die nicht den erwarteten Mustern entsprechen, werden unmittelbar abgewiesen. Dadurch lassen sich viele typische Angriffsmethoden wirksam verhindern.

4. Defense in Depth: Kompartimentierung

Trusted Applications sind Teil eines größeren Ökosystems. Sicherheit darf niemals von einer einzelnen Schutzmaßnahme abhängen. Das Prinzip Defense in Depth sorgt dafür, dass ein erfolgreicher Angriff auf eine Ebene nicht automatisch das gesamte System kompromittiert.

Innerhalb der TEE wird dies durch Kompartimentierung umgesetzt. Funktionen werden in voneinander getrennte Komponenten aufgeteilt, die jeweils über eigene Zugriffsrichtlinien verfügen. Eine Schwachstelle in einem Modul darf nicht zur Gefährdung anderer Module führen.

Beispielsweise sollte eine Trusted Application für das Schlüsselmanagement vollständig von Funktionen für Diagnostik oder Kommunikationsprotokolle getrennt sein. Diese Isolation begrenzt Schäden und vereinfacht gleichzeitig die Fehlerbehebung und das Patch-Management.

Moderne Fahrzeugarchitekturen kombinieren hierfür mehrere Schutzebenen, darunter Secure Boot, Hardware-Isolation, Laufzeitprüfungen und verschlüsselte Kommunikation. Das Ergebnis ist eine mehrschichtige Sicherheitsarchitektur, die selbst komplexen Angriffsszenarien widersteht.

5. Secure Defaults und Fail-Safe Design

Kein System ist vollkommen fehlerfrei. Die entscheidende Frage lautet daher nicht, ob Fehler auftreten, sondern wie das System darauf reagiert. Genau hier greifen die Prinzipien Secure Defaults und Fail-Safe Design.

Secure Defaults bedeuten, dass eine Trusted Application grundsätzlich mit restriktiven Einstellungen startet. Zugriffe werden standardmäßig verweigert und nur dann freigegeben, wenn sie ausdrücklich erforderlich sind.

Fail-Safe Design definiert, wie sich Ressourcen bei Fehlern oder Inkonsistenzen verhalten sollen. Kommt es zu einer Anomalie, etwa einem unerwarteten Firmware-Hash-Mismatch, einem beschädigten Schlüssel oder einer fehlerhaften Sitzung, muss die Trusted Application den Vorgang standardmäßig ablehnen.

Gerade in Automotive-Anwendungen ist dieses Verhalten entscheidend. Trifft eine OTA-Update-TA beispielsweise auf unvollständige Signaturdaten, muss der Update-Prozess sicher gestoppt werden. Würde das System die Aktualisierung dennoch zulassen, könnte dies die Integrität des gesamten Fahrzeugnetzwerks gefährden.

Durch die konsequente Verankerung dieser Prinzipien bereits in der Designphase gewährleisten Trusted Applications in Software Defined Vehicles Vorhersehbarkeit, Resilienz und sichere Fehlerbehandlung auch unter unerwarteten Bedingungen.

6. Auditierbarkeit und messbare Sicherheit

Kein Sicherheitskonzept ist vollständig ohne Transparenz. Auditierbarkeit stellt sicher, dass alle Aktionen nachvollziehbar, überprüfbar und analysierbar bleiben.

Sicher innerhalb der TEE gespeicherte Protokolle dokumentieren wichtige Ereignisse wie Zugriffsversuche, Validierungsfehler und betriebliche Auffälligkeiten. Diese Informationen unterstützen sowohl forensische Analysen als auch die Einhaltung von Vorgaben wie ISO/SAE 21434.

Moderne Cybersecurity geht jedoch über reine Protokollierung hinaus. Gefordert wird messbare Sicherheit (Measurable Assurance). Darunter versteht man die kontinuierliche Bewertung, Prüfung und Nachweisbarkeit des Sicherheitsniveaus anhand definierter Metriken.

Durch die Integration von Auditierbarkeit und Assurance in das Design von Trusted Applications erhalten OEMs belastbare Nachweise darüber, dass ihre digitalen Vertrauensmechanismen wie vorgesehen funktionieren.

OP-TEE und seine Rolle bei der Durchsetzung sicherer Designprinzipien

Designprinzipien sind nur so wirksam wie ihre technische Umsetzung. Für die Umsetzung von Isolation, Integrität und Richtliniendurchsetzung auf Hard- und Softwareebene ist ein geeigneter Framework-Ansatz erforderlich.

Hier kommt OP-TEE (Open Portable Trusted Execution Environment) ins Spiel.

OP-TEE ist eine Open-Source-Implementierung eines TEE-Frameworks und wird in Automotive- sowie Embedded-Systemen breit eingesetzt. Es bietet die Grundlage für die Entwicklung, das Testen und den Betrieb von Trusted Applications gemäß den Spezifikationen von GlobalPlatform.

Durch OP-TEE können Trusted Applications in isolierten, hardwaregestützten Umgebungen ausgeführt werden. Der Zugriff auf Speicher, kryptografische Schlüssel und Systemressourcen wird kontrolliert und abgesichert. Zudem erzwingt das Framework sichere Interaktionen zwischen REE und TA, indem sämtliche Eingaben, Befehle und Datenaustausche vor der Verarbeitung validiert werden.

Fehler oder unerwartete Eingaben führen automatisch zu sicheren Standardreaktionen und verhindern die Ausbreitung unsicherer Zustände im Fahrzeug. Darüber hinaus unterstützt OP-TEE ein sicheres Lifecycle-Management und umfangreiche Audit-Funktionen, wodurch OEMs das Verhalten ihrer Trusted Applications kontinuierlich überwachen und bewerten können.

Häufige Fehler bei der Implementierung von OP-TEE

Selbst ein robustes Framework wie OP-TEE kann fehlerhaft eingesetzt werden. Zu den häufigsten Problemen zählen:

1. Type Confusion

Type Confusion tritt auf, wenn Daten als anderer Datentyp interpretiert werden als ursprünglich vorgesehen. Besonders an der REE-TEE-Grenze kann dies zur Manipulation von Speicherinhalten oder zur Umgehung von Sicherheitsmechanismen führen.

2. Unchecked Marshalling

Marshalling beschreibt das Verpacken und Entpacken von Daten für die Kommunikation zwischen REE und TEE. Werden eingehende Daten ungeprüft verarbeitet, können Buffer Overflows, unerwartetes Verhalten oder Privilege Escalation entstehen.

3. Unsachgemäße Speicherverwaltung

Fehler wie Buffer Overflows, Dangling Pointer oder nicht initialisierte Speicherbereiche sind in Trusted Applications besonders kritisch. Sie können interne Zustände manipulieren oder sensible Informationen offenlegen.

4. Unzureichende Eingabevalidierung

Jede Eingabe, die eine Trusted Application erreicht, muss als potenziell bösartig betrachtet werden. Fehlende oder unzureichende Validierungsmechanismen können Angriffe wie Injection-Attacken, manipulierte Requests oder die Umgehung von Authentifizierungsmechanismen ermöglichen.

Fazit

Die sicheren Designprinzipien hinter Trusted Applications bilden das Fundament der Fahrzeugsicherheit moderner Fahrzeuge. Ihre Wirksamkeit hängt jedoch nicht allein von der Trusted Execution Environment ab, sondern von einer konsequenten Umsetzung über den gesamten Entwicklungsprozess hinweg.

Diese Prinzipien sind weit mehr als technische Richtlinien. Sie sind grundlegende Leitlinien, die eine Anwendung von einer lediglich „Trusted“ genannten Lösung zu einer tatsächlich vertrauenswürdigen Sicherheitskomponente machen.

Wenn OEMs diese Prinzipien in alle Ebenen der Entwicklung von Trusted Applications integrieren, schaffen sie die Grundlage für einen Wechsel von reaktiven Sicherheitsmaßnahmen hin zu proaktivem Vertrauen und damit für Fahrzeuge, die sicher, resilient und den Anforderungen zukünftiger Software-definierter Mobilität gewachsen sind.