Ein Beispiel für die Absicherung der KI in der Kabine mit TEE auf einem sicheren FPGA-SoC

Dieser Artikel beschreibt vertrauenswürdige Ausführungsumgebungen, die bereits in einer Vielzahl von verbundenen Geräten verwendet werden, indem er zeigt, wie die Verwendung von TEE und einem FPGA-SoC in Fahrzeugen funktionieren kann. Kabinen-KI.

In Teil I dieses Artikels, Trusted Execution Environments (TEEs) in Connected Cars, wurde erörtert, dass eine Trusted Execution Environment (TEE) zwar auf Mobiltelefonen und anderen vernetzten Geräten weit verbreitet ist, um kritische Funktionen abzusichern, die Akzeptanz in vernetzten Fahrzeugen jedoch gering ist. Das Fehlen von TEE kann Systemschwachstellen schaffen. In Teil II nehmen wir die KI in der Kabine als Beispielanwendung und diskutieren, wie ein moderner TEE- und FPGA-SoC seine sichere Plattform sein kann.

Typisches KI-System in der Kabine

Die KI in der Kabine ist Teil eines fortschrittlichen Fahrerassistenzsystems (ADAS) und wird tatsächlich häufiger eingesetzt als autonomes Fahren. Die KI in der Kabine nutzt Kameras oder andere Sensoren, um Fahrern und Passagieren kontextbezogene Sicherheitshinweise zu geben oder Optionen wie Sprache oder Gesten zur Steuerung des Fahrzeugs bereitzustellen. Nach innen gerichtete Kameras können beispielsweise Lkw-Fahrer überwachen, um Rausch, Ablenkung, Schläfrigkeit und Müdigkeit zu erkennen, um den Fahrer zu warnen und Unfälle zu vermeiden. Diese werden derzeit häufig in Nutzfahrzeugen und Lastkraftwagen eingesetzt. Dieselbe Technologie beginnt, in Verbraucherfahrzeuge einzudringen, um das fahrerbezogene Verhalten aus Sicherheitsgründen zu beobachten. KI-betriebene Kameras können auch warnen, wenn Kinder und Haustiere im Fahrzeug zurückgelassen werden, um hitzebedingte Todesfälle zu vermeiden.

Ein typisches System in der Kabine überwacht das Fahrerverhalten, überprüft, ob die Insassen angeschnallt sind, und kann darauf trainiert werden, interessante Objekte wie Mobiltelefone, Schlüsselanhänger, Kindersitze usw. zu verfolgen. Das System muss viele Funktionen erfüllen, einschließlich einer auf maschinellem Lernen basierenden Videosignalkette , Kommunikation mit anderen Steuergeräten wie dem zentralen ADAS oder dem Infotainment-System und Unterstützung von Firmware-Upgrades.

Es kann auch eine Totwinkelerkennung durchführen – mit kleinen Kameras ergänzte Seitenrückspiegel können verwendet werden, um ML-Algorithmen auszuführen, um Fahrzeuge im toten Winkel des Fahrers zu erkennen. Darüber hinaus kann es Verarbeitungen wie die fahrzeuginterne Netzwerkauthentifizierung (IVN) vom zentralen ADAS auslagern.

Ein Beispiel für gehärtete Hardware

Das PolarFire SoC FPGA von Microchip ist ein Beispiel für Hardware, die diese Art von konsolidierten Funktionen und Systemen mit gemischter Kritikalität unterstützen kann. Es ermöglicht KI-Anwendungen in der Kabine mit effizienter Inferenz auf dem FPGA-Fabric und dem Mikroprozessor-Subsystem, um Steuerungs- und Überwachungsjobs auszuführen. Es unterstützt deterministisches RTOS zusammen mit reichhaltigem Linux auf äußerst energieeffizienten Quad-Core-RISC-V-Prozessoren (siehe Abbildung 1).

Abbildung 1. PolarFire SoC-KI-Plattform in der Kabine. ML-Inferenz läuft auf FPGA-Fabric. RISC-V SoC hostet Steuerungs- und Überwachungsfunktionen.

Um die Hardware zu härten, verfügt PolarFire SoC über integrierte Sicherheitsmaßnahmen, die manipulationssichere Unterstützung sowie Gegenmaßnahmen zur Differential-Power-Analyse (DPA) umfassen. Dies schützt den Chip vor Seitenkanal-Exploits, die darauf abzielen, Bitstreams zu extrahieren, und verhindert so das Klonen. Durch die sichere Programmierinfrastruktur hat ein Automobilhersteller die volle Kontrolle über die Anzahl der programmierbaren FPGAs und schützt so vor Überbauung. PolarFire SoC unterstützt auch sicheres Booten mit einem SECDED-aktivierten integrierten sicheren 128-kB-Boot-Flash-Speicher.

KI-Inferenzmodell und andere wertvolle Datenbestände müssen geschützt werden

Zu den wertvollen Datenbeständen dieses Systems gehören:

• IVN – unbeabsichtigter Zugriff auf das IVN („CAN-Bus“) kann einem Gegner ermöglichen, das Fahrzeug zu übernehmen
• Personenbezogene Identifizierbare Informationen (PII) von Fahrer und Beifahrer – PII sollten aus Gründen der Privatsphäre der Verbraucher verborgen werden
• OTA – Wenn OTA-Code oder -Daten beschädigt oder gekapert sind, kann schlechte oder bösartige Firmware eingeschleust werden
• KI-Modell – Inferenzmodell ist anfällig für IP-Diebstahl und -Angriffe
• Geheimnisse – Schlüssel und Kryptobibliotheken müssen abgeschirmt werden, um den digitalen Signaturalgorithmus (DSA) von IVN-Nachrichten sicherzustellen

Die Vertraulichkeit, Integrität und Verfügbarkeit (CIA) dieser Assets muss beim Design berücksichtigt werden.

Angriffsflächen und Bedrohungen für diese Assets umfassen:

Angriffsflächen	Exploits
Anwendungs- und Netzwerkschichten	Malware, Pufferüberlauf um IVN, OTA auszunutzen, PII zu stehlen
Rich-Betriebssystem	Ein umfangreiches Betriebssystem wie Linux hat eine große Angriffsfläche. Jede unfreie Firmware bringt auch Undurchsichtigkeit und Risiken mit sich. Exploits können das gesamte System lahmlegen oder es einem Gegner ermöglichen, heimlich über das reichhaltige Betriebssystem einzudringen, um andere Assets zu manipulieren.
Sensoren	„Model Hacking“ oder „Adversarial Machine Learning“ ist, wenn nicht vertrauenswürdige Anwendungen auf den Sensorspeicher zugreifen. Malware kann den Sensorspeicher stören, was zu einem unbeabsichtigten Betrieb von ADAS führt.
Sensoren	“Inversion by Surrogate Model”:Wenn ein Gegner die Eingabe kontrollieren und die Ausgabe des Inferenzmodells beobachten kann, indem er in der Lage ist, in den Speicher zu lesen und zu schreiben, kann er das Modell neu erstellen. Er könnte diese Kopie verwenden, um Trends und Verteilungen in den Trainingsdaten zu lernen oder zukünftige Angriffe zu planen.

Ein Beispiel für eine vertrauenswürdige Ausführungsumgebung

Ein TEE, das Sicherheit durch Trennung bietet, ist eine hervorragende Gegenmaßnahme, um ein Zero-Trust-Modell zum Schutz dieser Datenbestände zu entwickeln.

Ein TEE, das einen neuen Ansatz verfolgt, ist MultiZone® Security von Hex Five. Es verwendet Speicherpartitionsprimitive:„Physical Memory Protection“ PMP, das auf allen RISC-V Standard ist, oder „Memory Protection Unit“ MPU auf Arm®, und Berechtigungsstufen in der CPU (M-Modus und U-Modus für RISC- V, Handler- und Thread-Ebenen für Arm®), um mehrere sichere Container oder Zonen zu erstellen.

Eine Konfiguration von MultiZone auf dem PolarFire SoC kann wie in Abbildung 2 aussehen. Jedes rote Kästchen zeigt einen Funktionsblock an, der in einem „Container“ oder einer „Zone“ geschützt ist. Innerhalb jeder Zone kann nur autorisierter und zugewiesener Code auf bestimmte Speicherbereiche gemäß den Lese-Schreib-Ausführungsberechtigungen zugreifen, die von einer MultiZone-Richtliniendatei eingerichtet wurden. Interrupt-Handler werden einer Zone zugewiesen, damit sie nur mit Benutzermodus-Privilegien anstelle des Kernel-Modus ausgeführt wird, um dem Zero-Trust-Modell zu entsprechen.

Die fünf Zonen sind:

1. OTA– Schützt den CIA vor OTA-Code und -Daten
2. Kamera – Sichert die Kamerasensordaten
3. IVN-Authentifizierung – Ähnlich wie bei einem HSM sichert diese Zone die Schlüssel und Krypto für DSA
4. RTOS – Steuert das IVN
5. Linux Enclave – Fehler von Linux werden eingedämmt

Diese Zonen sind in Abbildung 2 dargestellt.

Abbildung 2. MultiZone erstellt 5 „Zonen“ auf dem PolarFire SoC. Nur MultiZone läuft im M-Modus, der CPU Ring 0 auf RISC-V ist. Jedes rote Kästchen ist eine softwaredefinierte, durch Hardware getrennte Zone .

Diese Beispielkonfiguration zeigt, wie ein TEE und seine Begleithardware eine grundlegende sichere Plattform für eine kabineninterne KI-Anwendung schaffen.

TEE ist eine grundlegende Schicht

Eine gute Sicherheitsposition für vernetzte Fahrzeuge sollte mindestens Folgendes umfassen:

• Anwendungssicherheit
• Intrusion Detection Prevention System (IDPS) für die Netzwerksicherheit
• Sicheres OTA
• Vertrauenswürdige Ausführungsumgebung
• Hardware mit integrierten Sicherheitsprimitiven, Root-of-Trust

Die Untermauerung von TEEs in unseren Fahrzeugen ist von entscheidender Bedeutung, nicht anders als TEEs in unseren Telefonen. Das ist ein Weg, unsere Autos sicherer zu machen als unsere Smartphones.

Dieser Artikel wurde von Diptesh Nandi von Microchip mitverfasst.

Branchenartikel sind eine Inhaltsform, die es Branchenpartnern ermöglicht, nützliche Nachrichten, Nachrichten und Technologien mit All About Circuits-Lesern auf eine Weise zu teilen, für die redaktionelle Inhalte nicht gut geeignet sind. Alle Branchenartikel unterliegen strengen redaktionellen Richtlinien, um den Lesern nützliche Neuigkeiten, technisches Know-how oder Geschichten zu bieten. Die in Branchenartikeln zum Ausdruck gebrachten Standpunkte und Meinungen sind die des Partners und nicht unbedingt die von All About Circuits oder seinen Autoren.