Perspectives techniques
Common-Mode Noise Injection on the HS Portion of a D-PHY Pattern
5 min
Grâce à l’intégration de la spécification MIPI Camera Service Extensions (CSESM) aux modèles SV5C-DPTXCPTX et SV5C-DPRXCPRX d’Introspect Technology, nous aidons le secteur automobile à valider les fonctionnalités de sécurité et de sûreté fonctionnelle des capteurs d’image et des unités de contrôle électroniques (ECU). Mais qu’est-ce que la spécification MIPI CSE exactement, et quel est son lien avec la spécification MIPI CSI-2® ? Poursuivez votre lecture pour découvrir comment le secteur normalise les processus de chiffrement et de sécurité sur les systèmes de vision développés pour la conduite autonome.
Le CSE est une couche d’application normalisée qui s’appuie sur le CSI-2
De plus en plus, les architectures des calculateurs de conduite autonome (ECU) s’attachent à garantir la sécurité et la sûreté fonctionnelle sur l’ensemble du chemin de transmission des données, depuis un capteur d’image (ou un capteur radar) jusqu’aux moteurs de traitement du calculateur, en passant par les câbles et les dispositifs de liaison. Pour y parvenir, les développeurs sont actuellement contraints de créer leurs propres algorithmes de chiffrement et de cryptographie propriétaires, comme l’illustre la figure 1 (a).
Les défis liés à la mise en œuvre d’algorithmes cryptographiques propriétaires sont de deux ordres. D’une part, chaque implémentation système nécessite un effort d’ingénierie considérable. Mais surtout, la mise en œuvre d’algorithmes propriétaires nécessite l’ajout de composants et d’éléments de traitement supplémentaires. Cela augmente le coût, le poids et la complexité de tout système de conduite autonome.
La spécification MIPI CSE constitue donc une couche d’application normalisée permettant de définir le chiffrement et la cryptographie dans un système de vision basé sur MIPI, comme l’illustre la figure 1(b). L’arrivée de cette couche d’application peut offrir plusieurs avantages aux intégrateurs de systèmes. Par exemple, si un capteur d’image intègre directement la norme MIPI CSE, un intégrateur de systèmes n’a pas besoin d’ajouter de composants supplémentaires pour le chiffrement et l’authentification des messages. De plus, tout fabricant de CPU ou de GPU peut normaliser la conception de ses récepteurs et ainsi réduire les coûts d’ingénierie non récurrents à long terme.
Les entrées d’un bloc MIPI CSE sont variées et comprennent naturellement les données de pixels du capteur d’image ainsi que les données de contrôle liées à l’authentification et au chiffrement. Parallèlement, la sortie d’un bloc CSE MIPI est toujours un flux CSI-2. Autrement dit, pour un contrôleur MIPI CSI-2 de bas niveau, le bloc CSE MIPI apparaît comme s’il s’agissait d’un capteur, ce qui est décrit ci-après.
La spécification MIPI CSE transforme les flux MIPI CSI-2
En vous référant à la figure 2, vous pouvez observer les deux types de paquets pris en charge par la norme MIPI CSI-2. Dans la première partie de la figure, vous trouverez la définition d’un paquet court, utilisé pour signaler les paquets de début ou de fin de trame. Dans la deuxième partie de la figure, nous présentons la structure d’un paquet long. Dans un paquet court, le périphérique source (tel qu’un capteur d’image) transmet 4 octets d’en-tête, et les champs de l’en-tête sont en grande partie vides. Aucune autre donnée n’est envoyée après l’en-tête dans un paquet court. En revanche, lorsqu’un paquet long est transmis, les octets d’en-tête contiennent des informations importantes telles que le type de données du paquet envoyé, le nombre de mots transmis dans le paquet, ainsi que certains codes de correction d’erreurs. Et bien sûr, les données utiles sont transmises après les 4 octets d’en-tête, et deux octets sont ajoutés à la fin du paquet pour le CRC.
Prenons l’exemple du paquet « Frame Start » pour voir comment ce paquet simple est transformé par une couche applicative CSE. La figure 3 présente la structure complète du paquet « Frame Start » après son traitement par la couche CSE. Tout d’abord, il est important de noter qu’il s’agit d’un paquet CSI-2 100 % compatible. Le protocole de communication MIPI CSI-2 n’a subi aucune modification. Nous avons simplement transformé le paquet court en un paquet long. Cela s’explique par le fait que la couche CSE MIPI a ajouté des informations « d’encapsulation » autour du paquet « Frame Start ». Ces informations d’encapsulation comprennent notamment un chiffrement.
Si l’on examine maintenant les octets d’en-tête de ce nouveau paquet illustré à la figure 3, on constate que le premier octet a pour valeur 0x3E ; il s’agit d’un nouveau type de données qui indique au contrôleur MIPI CSI-2 que les données transmises sont des « données CSE ». Cela rappelle le type de données 2E de la norme CSI-2, qui sert à désigner les données non intégrées à une image dans le cadre de cette norme. Le reste de l’en-tête est conforme au protocole MIPI CSI-2 : par exemple, les octets 0x12 et 0x00 indiquent le nombre de mots dans ce long paquet, et les deux derniers octets sont des octets CRC.
Outre l’en-tête et les octets CRC, pourquoi a-t-il fallu envoyer 18 octets de charge utile pour simplement indiquer le début d’une trame ? C’est là le cœur de la spécification MIPI CSE. Elle chiffre les données envoyées de sorte que l’interception du paquet ne permette pas de déterminer s’il s’agit ou non d’un début de trame. Elle ajoute également des messages d’authentification pour aider le destinataire à déchiffrer le paquet. Il s’agit d’un protocole complexe, mais ne désespérez pas : Introspect dispose de capacités de validation complètes, et nous allons vous les présenter ci-après !
Validation des spécifications MIPI CSE et génération de vecteurs par Introspect
Introspect a développé une suite complète d’outils permettant de générer des données CSE (à partir des données des capteurs d’image) ainsi que de décoder et de valider les données chiffrées au format CSE. Cela facilite considérablement le processus de conception d’une couche applicative CSE et garantit également que le secteur dispose d’un référence absolue pour les tests d’interopérabilité. En vous reportant à la figure 4, nous vous présentons un exemple de capture de protocole d’un flux MIPI CSE. Comme vous pouvez le constater, la partie supérieure de la fenêtre d’affichage montre l’évolution temporelle des paquets reçus, qui sont tous désignés comme des paquets « sep » ou « 3E ». En d’autres termes, les détails relatifs à la trame basée sur le CSI sont entièrement masqués en raison de la mise en paquets prévue par le protocole SEP (Service Extension Packet). Le panneau inférieur montre ensuite comment l’un de ces paquets « sep » est décodé, ce qui révèle la transmission d’image sous-jacente définie dans ce paquet. Plus précisément, le paquet illustré sur cette figure est un paquet long RGB888. On observe également la valeur du code d’authentification de message (MAC) : 0xE199122C. L’obtention de ce type d’informations détaillées est essentielle pour concevoir et valider rapidement la spécification MIPI CSE.
Vous trouverez ci-dessous une courte vidéo de présentation de la licence d’analyse MIPI CSE avec le logiciel Pinetree d’Introspect, primé à plusieurs reprises. Les spectateurs découvriront comment envoyer un modèle d’image CSI et activer les paramètres de sécurité CSE.
?enablejsapi=1&autoplay=0&cc_load_policy=0&cc_lang_pref=&iv_load_policy=1&loop=0&rel=0&fs=1&playsinline=0&autohide=2&theme=dark&color=red&controls=1&disablekb=0& » class= »__youtube_prefs__ epyt-is-override no-lazyload » title= »YouTube player » allow= »fullscreen; accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share » referrerpolicy= »strict-origin-when-cross-origin » allowfullscreen data-no-lazy= »1″ data-skipgform_ajax_framebjll= » »>
Résumé
La spécification MIPI CSE est une couche applicative qui s’appuie sur le protocole de bas niveau MIPI CSI-2. Dans cet article, nous avons présenté les concepts de base de cette couche applicative et expliqué comment elle est utilisée pour transformer les données des capteurs d’image en flux de paquets CSI-2 chiffrés. Comme vous pouvez l’imaginer, la spécification MIPI CSE est un protocole très complexe, qui comprend de très nombreuses variantes et options tant en matière de sécurité que de sécurité fonctionnelle. Sans les outils Introspect permettant de valider toutes ces options, la conception de systèmes de conduite autonome sécurisés devient une tâche extrêmement ardue !
Alors, trinquons à un voyage en toute sécurité lors de votre prochain road trip estival.
Pour plus d’informations sur les solutions CSE et CSI-2 d’Introspect, envoyez-nous un e-mail à l’adresse info@introspect.ca.
