Un exemple de sécurisation de l'IA en cabine à l'aide de TEE sur un SoC FPGA sécurisé

Cet article traite des environnements d'exécution de confiance - déjà utilisés dans une variété d'appareils connectés - en montrant comment l'utilisation de TEE et d'un SoC FPGA peut fonctionner dans un véhicule. IA de la cabine.

La première partie de cet article, Trusted Execution Environments (TEEs) in Connected Cars, a expliqué que si un Trusted Execution Environment (TEE) est largement utilisé sur les téléphones mobiles et autres appareils connectés pour sécuriser les fonctions critiques, son adoption dans les véhicules connectés est faible. L'absence de TEE peut créer des vulnérabilités du système. Dans la deuxième partie, nous prendrons l'IA en cabine comme exemple d'application et expliquerons comment un SoC TEE et FPGA moderne peut être sa plate-forme sécurisée.

Système d'IA en cabine typique

L'IA en cabine fait partie d'un système avancé d'aide à la conduite (ADAS) et est en fait plus répandue que la conduite autonome. L'IA en cabine utilise des caméras ou d'autres capteurs pour donner aux conducteurs et aux passagers des conseils de sécurité contextuels, ou fournir des options telles que la voix, les gestes pour contrôler le véhicule. Par exemple, les caméras orientées vers l'intérieur sont aptes à surveiller les chauffeurs de camion pour détecter l'ivresse, la distraction, la somnolence et la fatigue afin d'alerter le conducteur et de prévenir les accidents. Ceux-ci sont actuellement largement déployés dans les véhicules utilitaires et les camions. La même technologie commence à pénétrer les véhicules grand public pour observer le comportement du conducteur à des fins de sécurité. Les caméras alimentées par l'IA peuvent également alerter lorsque des enfants et des animaux domestiques sont laissés dans le véhicule pour éviter les décès liés à la chaleur.

Un système typique en cabine surveille le comportement du conducteur, vérifie si les occupants portent des ceintures de sécurité et peut être formé pour suivre des objets d'intérêt comme les téléphones portables, les porte-clés, les sièges bébé, etc. Le système doit accomplir de nombreuses fonctions, y compris la chaîne de signaux vidéo basée sur l'apprentissage automatique. , communication avec d'autres calculateurs comme l'ADAS central ou le système d'infodivertissement, et prend en charge les mises à niveau du micrologiciel.

Il peut également effectuer une détection d'angle mort - des rétroviseurs latéraux complétés par des caméras à petit facteur de forme peuvent être utilisés pour exécuter des algorithmes ML pour repérer les véhicules dans l'angle mort du conducteur. De plus, il peut décharger le traitement tel que l'authentification du réseau embarqué (IVN) de l'ADAS central.

Un exemple de matériel renforcé

Le FPGA PolarFire SoC de Microchip est un exemple de matériel pouvant prendre en charge ce type de fonctions consolidées, système à criticité mixte. Il permet aux applications d'IA en cabine avec une inférence efficace sur la matrice FPGA et le sous-système de microprocesseur d'exécuter des tâches de contrôle et de surveillance. Il prend en charge le RTOS déterministe ainsi que Linux riche sur des processeurs RISC-V quadricœurs à haute efficacité énergétique (voir Figure 1).

Figure 1. Plateforme d'IA en cabine SoC PolarFire. L'inférence ML s'exécute sur la structure FPGA. Le SoC RISC-V héberge des fonctions de contrôle et de surveillance.

Pour renforcer le matériel, PolarFire SoC a des mesures de sécurité intégrées qui incluent une prise en charge inviolable ainsi que des contre-mesures d'analyse de puissance différentielle (DPA). Cela protège la puce contre les exploits de canaux latéraux visant à extraire des flux binaires et empêche ainsi le clonage. En utilisant l'infrastructure de programmation sécurisée, un constructeur automobile a un contrôle total sur le nombre de FPGA pouvant être programmés, protégeant ainsi contre la surconstruction. Le SoC PolarFire prend également en charge le démarrage sécurisé à l'aide d'une mémoire flash de démarrage sécurisée intégrée de 128 ko, activée par SECDED.

Le modèle d'inférence d'IA et d'autres actifs de données de valeur doivent être protégés

Sur ce système, les actifs de données précieux incluent :

• IVN – un accès involontaire à l'IVN (« bus CAN ») peut permettre à un adversaire de prendre le contrôle du véhicule
• Informations personnelles identifiables (PII) du conducteur et du passager :les informations personnelles doivent être masquées pour la confidentialité des consommateurs
• OTA :si le code ou les données OTA sont corrompus ou piratés, un micrologiciel défectueux ou malveillant peut être injecté
• Modèle d'IA :le modèle d'inférence est sensible au vol et aux attaques IP
• Secrets :les clés et les bibliothèques de chiffrement doivent être protégées pour garantir l'algorithme de signature numérique (DSA) des messages IVN

La confidentialité, l'intégrité et la disponibilité (CIA) de ces actifs doivent être prises en compte lors de la conception.

Les surfaces d'attaque et les menaces pesant sur ces actifs incluent :

Surfaces d'attaque	Exploits
Couches application et réseau	Malware, débordement de tampon pour exploiter IVN, OTA, voler des PII
Système d'exploitation riche	Un système d'exploitation riche tel que Linux a une grande surface d'attaque. Tout firmware non libre introduit également de l'opacité et des risques. Les exploits peuvent détruire l'ensemble du système ou permettre à un adversaire d'entrer en silence via le riche système d'exploitation pour manipuler d'autres actifs.
Capteurs	« Piratage de modèle » ou « Apprentissage machine contradictoire » se produit lorsque la mémoire du capteur est accessible par des applications non fiables, les logiciels malveillants peuvent perturber la mémoire du capteur, entraînant un fonctionnement involontaire d'ADAS.
Capteurs	« Inversion par modèle de substitution » :lorsqu'un adversaire peut contrôler l'entrée et observer la sortie du modèle d'inférence en étant capable de lire et d'écrire dans la mémoire, il peut recréer le modèle. Il pourrait utiliser cette copie pour connaître les tendances et les distributions dans les données d'entraînement ou pour planifier de futures attaques.

Un exemple d'environnement d'exécution de confiance

Un TEE qui fournit la sécurité par séparation est une excellente contre-mesure pour concevoir un modèle de confiance zéro pour protéger ces actifs de données.

Un TEE qui adopte une nouvelle approche est la sécurité MultiZone® de Hex Five. Il utilise des primitives de partition mémoire :PMP « protection mémoire physique » qui est standard sur tous les MPU RISC-V ou « unité de protection mémoire » sur Arm®, et des niveaux de privilèges dans le CPU (mode M et mode U pour RISC- Niveaux V, Handler et Thread pour Arm®) pour créer plusieurs conteneurs ou zones sécurisés.

Une configuration de MultiZone sur PolarFire SoC peut ressembler à la Figure 2. Chaque case rouge indique un bloc fonctionnel protégé dans un « conteneur » ou une « zone ». Dans chaque zone, seul le code autorisé et attribué peut accéder aux régions de mémoire spécifiées selon les autorisations de lecture-écriture-exécution définies par un fichier de stratégie MultiZone. Les gestionnaires d'interruption sont affectés à une zone afin qu'elle ne s'exécute qu'avec des privilèges en mode utilisateur au lieu du mode noyau, pour se conformer au modèle de confiance zéro.

Les cinq zones sont :

1. OTA– Protège la CIA du code et des données OTA
2. Appareil photo :sécurise les données du capteur de l'appareil photo
3. Authentification IVN :similaire à un HSM, cette zone sécurise les clés et la cryptographie pour le DSA
4. RTOS – Contrôle l'IVN
5. Linux Enclave - Les défauts de Linux seront contenus

Ces zones sont illustrées à la figure 2.

Figure 2. MultiZone crée 5 « zones » sur le SoC PolarFire. Seul MultiZone fonctionne en mode M qui est CPU Ring 0 sur RISC-V. Chaque case rouge est une zone définie par logiciel et séparée par le matériel .

Cet exemple de configuration montre comment un TEE et son matériel associé créent une plate-forme sécurisée de base pour une application d'IA en cabine.

TEE est une couche fondamentale

Une bonne posture de sécurité pour les véhicules connectés doit inclure au minimum :

• Sécurité des applications
• Système de prévention des intrusions (IDPS) pour la sécurité du réseau
• OTA sécurisé
• Environnement d'exécution de confiance
• Matériel avec primitives de sécurité intégrées, racine de confiance

Il est essentiel de soutenir les TEE sur nos véhicules, ce qui n'est pas différent d'avoir des TEE dans nos téléphones. C'est un moyen de rendre nos voitures plus sûres que nos smartphones.

Cet article a été co-écrit par Diptesh Nandi, de Microchip.

Les articles de l'industrie sont une forme de contenu qui permet aux partenaires de l'industrie de partager des nouvelles, des messages et des technologies utiles avec les lecteurs d'All About Circuits d'une manière qui ne convient pas au contenu éditorial. Tous les articles de l'industrie sont soumis à des directives éditoriales strictes dans le but d'offrir aux lecteurs des informations utiles, une expertise technique ou des histoires. Les points de vue et opinions exprimés dans les articles de l'industrie sont ceux du partenaire et pas nécessairement ceux d'All About Circuits ou de ses rédacteurs.