In-Cabin-KI mit Trusted Execution Environment auf sicherem FPGA SoC absichern

Dieser Artikel demonstriert, wie eine Trusted Execution Environment (TEE) in Kombination mit einem sicheren FPGA SoC In-Cabin-KI-Systeme in modernen Fahrzeugen schützen kann.

Teil I dieser Serie, „Trusted Execution Environments in Connected Cars“, erläuterte, dass TEEs auf Smartphones allgegenwärtig sind, ihre Einführung in Automobilsysteme jedoch begrenzt bleibt. Das Fehlen einer TEE kann kritische Fahrzeugfunktionen Angriffen aussetzen. In Teil II fokussieren wir uns auf In-Cabin-KI als Fallstudie und zeigen, wie eine zeitgemäße TEE und ein FPGA SoC ein robustes Sicherheitsfundament bilden.

Typisches In-Cabin-KI-System

In-Cabin-KI, eine Schlüsselkomponente fortschrittlicher Fahrerassistenzsysteme (ADAS), ist weiter verbreitet als vollautonomes Fahren. Mit Kameras oder anderen Sensoren liefert sie kontextbezogene Sicherheitshinweise und unterstützt intuitive Steuerung wie Sprache und Gesten. Beispielsweise überwachen nach innen gerichtete Kameras LKW-Fahrer auf Anzeichen von Trunkenheit, Ablenkung, Schläfrigkeit oder Müdigkeit und warnen sie zur Unfallverhütung. Diese Technologie ist bereits in gewerblichen Flotten üblich und dringt allmählich in Privatfahrzeuge vor, um die Fahrersicherheit zu erhöhen. KI-gestützte Kameras können auch erkennen, wenn Kinder oder Haustiere unbeaufsichtigt zurückgelassen werden, und so hitzebezogene Risiken mindern.

Eine typische In-Cabin-Plattform verfolgt Fahrerverhalten, überprüft Gurtanlegung und kann trainiert werden, Objekte von Interesse zu identifizieren – Handys, Schlüsselanhänger, Kindersitze und mehr. Sie muss Machine-Learning-Inferenz auf Videostreams ausführen, mit anderen ECUs kommunizieren (z. B. zentrales ADAS oder Infotainment) und sichere Firmware-Updates unterstützen. Zusätzliche Funktionen umfassen Toter-Winkel-Erkennung via Seiten-/Heckkameras und Auslagerung der IVN-Authentifizierung vom zentralen ADAS.

Hardware-Hardening-Beispiel

Microchips PolarFire SoC FPGA exemplifiziert eine Plattform, die Mixed-Criticality-Workloads integrieren kann. Sie liefert effiziente ML-Inferenz auf FPGA-Gewebe, während der Quad-Core-RISC-V-Prozessorsubsystem Steuerungs- und Überwachungsaufgaben übernimmt. Das System unterstützt ein deterministisches RTOS neben einer stromsparenden Linux-Distribution, wie in Abbildung 1 illustriert.

Abbildung 1. PolarFire SoC In-Cabin-KI-Plattform. ML-Inferenz läuft auf FPGA-Gewebe. RISC-V SoC hostet Steuerung und Monitoring.

Der PolarFire SoC beinhaltet Hardwaresicherheitsfeatures wie manipulationssicheres Gehäuse, Differential-Power-Analysis (DPA)-Gegenmaßnahmen und Secure Boot via SECDED-aktivierten 128-kB-Boot-Flash. Diese Maßnahmen schützen das Gerät vor Seitenkanalangriffen, verhindern Bitstream-Klonen und ermöglichen Automobilherstellern, die FPGA-Programmierung auf autorisierte Einheiten zu beschränken.

Schutz von KI-Inferenzmodellen und Datenassets

Kritische Datenassets auf dieser Plattform umfassen:

• IVN (CAN-Bus) – unbefugter Zugriff könnte Fahrzeugsteuerung kompromittieren.
• Fahrer- und Insassen-PII – muss für Datenschutzkonformität vertraulich bleiben.
• OTA-Code und -Daten – müssen gegen Korruption oder Hijacking resistent sein.
• KI-Inferenzmodelle – anfällig für Diebstahl geistigen Eigentums oder Model-Poisoning-Angriffe.
• Kryptografische Geheimnisse – essenziell für Authentifizierung von IVN-Nachrichten.

Design für Vertraulichkeit, Integrität und Verfügbarkeit (CIA) ist essenziell, um diese Assets zu schützen. Typische Angriffsflächen und Bedrohungen umfassen:

Implementierung einer Trusted Execution Environment

Eine TEE, die Security-by-Separation erzwingt, ist ein mächtiges Gegenmittel für eine Zero-Trust-Architektur. Hex Five's MultiZone® Security nutzt beispielsweise Speicherpartition-Primitiven (PMP auf RISC-V, MPU auf ARM) und CPU-Privilegienebenen, um isolierte Zonen zu schaffen. Auf dem PolarFire SoC partitioniert MultiZone das System in fünf sichere Container, wie in Abbildung 2 gezeigt.

Abbildung 2. MultiZone erstellt fünf Zonen auf PolarFire SoC. Nur MultiZone operiert im M-Mode (CPU Ring 0 auf RISC-V); jedes rote Feld bezeichnet eine softwaredefinierte, hardwaregetrennte Zone.

Die fünf Zonen sind:

1. OTA – schützt CIA von Over-the-Air-Updates.
2. Kamera – sichert Sensordatenströme.
3. IVN-Authentifizierung – funktioniert wie ein HSM, schützt kryptografische Schlüssel und Signaturen.
4. RTOS – steuert IVN-Verkehr.
5. Linux-Enklave – enthält Fehler, die vom Betriebssystem ausgehen.

Diese Konfiguration demonstriert, wie eine TEE zusammen mit gehärteter Hardware eine fundamentale sichere Plattform für In-Cabin-KI etabliert.

TEE als fundamentale Sicherheitsschicht

Eine robuste automobile Sicherheitshaltung sollte mindestens folgende Schichten umfassen:

• Anwendungsseitige Sicherheitskontrollen.
• Intrusion Detection/Prevention System (IDPS) für Netzwerkverkehr.
• Sichere OTA-Mechanismen.
• Trusted Execution Environment.
• Hardware mit eingebauten Sicherheitsprimitiven und Root of Trust.

Die Integration von TEEs in Fahrzeuge parallelt den Schutz moderner Smartphones und bietet einen Pfad zu höherer Fahrzeugsicherheit.

Dieser Artikel wurde koautoriert von Diptesh Nandi von Microchip.

Industry Articles bieten Partnern eine Möglichkeit, technische Einblicke mit All About Circuits Lesern zu teilen. Diese Artikel folgen strengen redaktionellen Richtlinien und spiegeln die Standpunkte des Partners wider, nicht notwendigerweise die von All About Circuits.