Brevet FR3158004A1 — publié le 20250704

Procédé de communication sécurisée entre un système embarqué et un réseau externe Procédé de communication sécurisée entre un système embarqué, notamment intégré dans un véhicule automobile, et un réseau externe, notamment un réseau de localisation, ledit système embarqué, notamment une unité de contrôle télématique, comportant au moins un environnement d’exécution riche relié à au moins une unité de contrôle électronique et destiné à recevoir des informations dudit réseau externe par le biais d’un module de connexion au réseau, ce dernier étant relié à un environnement d’exécution en confiance relié au moins audit environnement d’exécution riche et comportant un moteur d’authentification contenant une clé privée générée au préalable, l’environnement d’exécution riche et ladite au moins une unité de contrôle électronique comportant une clé publique associée à ladite clé privée, le procédé comportant au moins les étapes suivantes : lorsqu’une information en provenance du module de connexion au réseau est récupérée par l’environnement d’exécution en confiance, une étiquette d’authentification est générée par le moteur d’authentification de l’environnement d’exécution en confiance à l’aide de la clé privée contenue dans ce dernier, ladite étiquette d’authentification est transmise à l’environnement d’exécution riche, et lorsque ladite information est transmise à ladite au moins une unité de contrôle électronique reliée à l’environnement d’exécution riche, ladite étiquette d’authentification est transmise également et vérifiée grâce à ladite clé publique afin de sécuriser la communication de l’information. Figure pour l’abrégé : Fig. 1 Procédé de communication sécurisée entre un système embarqué et un réseau externe La présente invention concerne un procédé et un dispositif de communication sécurisée entre un système embarqué, notamment intégré dans un véhicule automobile, et un réseau externe. Les architectures automobiles modernes ont besoin de connaître le temps, c’est-à-dire l’heure, de manière sécurisée, par exemple pour des applications cryptographiques, pour empêcher l’utilisation de clés de sécurité ou de certificats expirés, empêcher l’utilisation de logiciels obsolètes, notamment dans le cadre d’attaques cyber de type downgrade , ou bien pour se connecter de manière sécurisée au Cloud. Des applications d’aide à la conduite et de « vehicule -to- everything » (V2X) peuvent également nécessiter l’obtention d’un temps de confiance, ou d’une localisation géographique (GNSS) précise et de confiance. D’autres applications requièrent également l’obtention de temps avec des contraintes de latence très faibles, de l’ordre de la milliseconde. Dans les architectures connues, les antennes et sous-systèmes GNSS sont localisées dans une unité de contrôle télématique ou modem, souvent appelé « Telematics Control Unit » (TCU), qui consiste en un cœur de processeur (SoC), accompagné de coprocesseurs, internes ou externes au cœur de processeur, ayant la fonction de modem LTE ou de récepteur GNSS. L’unité de contrôle télématique étant quasiment directement connecté à internet, elle est le vecteur d’attaque privilégié des cyberattaquants, et n’est donc généralement pas considérée comme un composant de confiance dans l’architecture zonale du véhicule. Les informations qui émanent de cette unité ne sont donc pas considérées de confiance, et ne sont pas utilisées dans les autres unités de contrôle électroniques. Dès lors, d’autres mécanismes sont utilisés pour contourner cela : des serveurs sont mis en place dans le Cloud, hébergeant une base de temps de confiance, comme un serveur NTP, et connectés avec un protocole propriétaire jusqu’aux composants de confiance du véhicule, notamment par propagation d’un token d’authentification du type JWT. L’information transite ainsi par l’unité de contrôle télématique, qui peut empêcher son transit mais ne peut pas rompre son authenticité. Cependant, ces mécanismes ont de nombreux inconvénients. Leur latence est élevée, et leur précision faible. L’utilisation de protocoles non-conçus pour la diffusion du temps ne permet pas une précision suffisante. Il y a ainsi dans le véhicule deux temps différents qui transitent : un temps de confiance mais peu précis, et un temps précis mais non-digne de confiance, et non utilisable pour des applications cryptographiques. Cela complexifie beaucoup l’architecture véhicule, les coûts de développement et de maintenance, et le risque de bugs ou de pannes. Les solutions connues nécessitent la maintenance d’un service dit « offboard » dans le Cloud, développé avec des briques propriétaires, engendrant des coûts importants d’hébergement et de bande-passante, la nécessité d’architectures cloud multi-tiers, pour l’obtention d’une garantie de disponibilité du service, et la maintenance ou la correction de bugs sur la durée du service. La multiplication des services, protocoles, et applicatifs « onboard / offboard » est généralement une mauvaise pratique du point de vue de la cybersécurité : cela implique plus de logiciels, plus de code, et donc plus de risques de bugs et de vulnérabilités aux cyberattaques. Il existe ainsi un besoin pour perfectionner encore les moyens pour favoriser les échanges de façon sécurisée entre un système embarqué, notamment intégré dans un véhicule automobile, et un réseau externe, notamment un réseau de télécommunications, afin de contrer les cyberattaques. Procédé de communication La présente invention répond à ce besoin grâce à, selon l’un de ses aspects, un procédé de communication sécurisée entre un système embarqué, notamment intégré dans un véhicule automobile, et un réseau externe, notamment un réseau de localisation, ledit système embarqué, notamment une unité de contrôle télématique, comportant au moins un environnement d’exécution riche relié à au moins une unité de contrôle électronique et destiné à recevoir des informations dudit réseau externe par le biais d’un module de connexion au réseau, ce dernier étant relié à un environnement d’exécution en confiance relié au moins audit environnement d’exécution riche et comportant un moteur d’authentification contenant une clé privée générée au préalable, l’environnement d’exécution riche et ladite au moins une unité de contrôle électronique comportant une clé publique associée à ladite clé privée, le procédé comportant au moins les étapes suivantes : lorsqu’une information en provenance du module de connexion au réseau est récupérée par l’environnement d’exécution en confiance, une étiquette d’authentification est générée par le moteur d’authentification de l’environnement d’exécution en confiance à l’aide de la clé privée contenue dans ce dernier, ladite étiquette d’authentification est transmise à l’environnement d’exécution riche, et lorsque ladite information est transmise à ladite au moins une unité de contrôle électronique reliée à l’environnement d’exécution riche, ladite étiquette d’authentification est transmise également et vérifiée grâce à ladite clé publique afin de sécuriser la communication de l’information.. Grâce à l’invention, une alternative visant à simplifier l’architecture d’acquisition et de distribution du temps dans le véhicule est proposée, en bénéficiant des techniques des systèmes embarqués modernes et des technologies GNSS d’authentification du temps. L’invention permet d’éviter le coûteux développement de mécanismes complémentaires externes, dits « offboard », visant à fournir un temps de confiance, dit « Trusted Time ». Le procédé selon l’invention évite également l’installation de récepteurs GNSS en Zone 3 du véhicule, ce qui est un gain de plusieurs dizaines d’euros par véhicule. Les coûts opérationnels pour le constructeur automobile sont significativement diminués, évitant d’héberger de nouveaux services Cloud avec un agrément de niveau de service (SLA pour « Service Level Agreement ») et la bande passante associée. Il est également possible de suivre les vulnérabilités liées aux services utilisés, pendant la durée de vie du véhicule. L’invention utilise les capacités des systèmes embarqués à héberger des environnements sécurisés, les environnements d’exécution en confiance ou TEE pour « Trusted Execution Environment », aussi appelés sous la dénomination commerciale TZ, TrustZone, ou SecureWorld, pour garantir l’authenticité et l’intégrité, mais pas la disponibilité, des signaux de localisation et de position, y compris si l’environnement d’exécution riche de l’unité de contrôle télématique (TCU) est compromis par un attaquant. L’environnement d’exécution en confiance est isolé et difficilement attaquable par un attaquant ayant compromis l’environnement d’exécution riche (userland ou kernel). L’invention permet de réaliser une chaîne de confiance complète, du satellite jusqu’aux unités de contrôle électronique au niveau des utilisateurs. Un attaquant compromettant le l’environnement d’exécution riche de l’unité de contrôle télématique peut corrompre l’information de temps et de localisation, ou l’étiquette, mais les unités de contrôle électronique distantes pourront détecter cette compromission, et empêcher l’utilisation de cette information erronée, et ne pas resynchroniser leur horloge par exemple. Dans un mode de réalisation préféré, le module de connexion au réseau est un sous-système GNSS, notamment un circuit intégré ou une puce externe. Cela permet de se prémunir contre des attaques radiofréquence à proximité du véhicule, notamment du type GNSS spoofing , et la détection du jamming . L’information en provenance du module de connexion au réseau est avantageusement une information de localisation et/ou de temps, calculée par le sous-système GNSS à partir des signaux radio qu’il reçoit. De manière préférée, au moins un capteur pluridimensionnel est relié à l’environnement d’exécution en confiance, notamment un accéléromètre et/ou un gyroscope, l’information en provenance du module de connexion au réseau étant combinée à au moins une information pluridimensionnelle reçue de ce capteur. Le capteur pluridimensionnel peut être un capteur 3D, 6D ou 9D. Dans les méthodes connues, des algorithmes complexes sont mis en œuvre dans l’environnement d’exécution riche, et l’information de position n’est pas directement accessible dans l’environnement d’exécution en confiance, ou en tous cas pas dans une version aussi précise, ou absente par exemple lorsque le signal GNSS est masqué, notamment, dans l’automobile, dans le cas d’un passage sous un tunnel ou une montagne. Dans l’invention, la fusion des informations pluridimensionnelles et de l’information en provenance du module de connexion au réseau peut être réalisée par l’environnement d’exécution en confiance. Cela offre une solution simple et résiliente. Dans une variante, ladite au moins une unité de contrôle électronique reçoit, avec l’étiquette d’authentification, au moins une information précise de localisation et/ou de temps de l’environnement d’exécution riche et une information préliminaire de l’environnement d’exécution en confiance, utilisée pour la génération de l’étiquette d’authentification. Cette méthode correspond à une vérification dite floue de la cohérence des temps et des localisations, par exemple en autorisant une déviation de quelques secondes ou de quelques kilomètres. En effet, les modules logiciels de fusion de données, dans l’environnement d’exécution riche, proposent une information de temps et de localisation très précise. Dans l’invention, le module d’authentification des données, dans l’environnement d’exécution en confiance, se base avantageusement sur une information préliminaire imprécise et potentiellement légèrement décalée dans le temps ou l’espace. Chaque unité de contrôle électronique distante peut ensuite vérifier l’authenticité du temps et de la localisation préliminaires. Si elle n’est pas authentique, aucune information de temps et de localisation ne pourra être utilisée. Si elle est authentique, le temps précis sera comparé au temps préliminaire, et la localisation précise comparée à la localisation préliminaire. Si le delta est trop grand, l’information sera ignorée, charge à chaque unité de contrôle électronique de définir quels seuils sont acceptables en fonction de leur utilisation. Dans un mode de réalisation préféré, le moteur d’authentification est un bloc logiciel ajouté dans l’environnement d’exécution en confiance, notamment sous la forme d’une application de confiance (TA), afin de réaliser l’authentification des informations émises par le module de connexion au réseau. De manière avantageuse, seul l’environnement d’exécution en confiance a accès à la clé privée. L’étiquette d’authentification peut être générée en utilisant les algorithmes RSA ou ECC. Ladite étiquette d’authentification peut être générée de façon asynchrone. Dans une application automobile, cela permet de ne pas ralentir la propagation du temps dans le véhicule, si des latences inférieures à 5 millisecondes sont nécessaires. Les applications ayant besoin de vérifier l’authenticité du temps ou de la position devront, elles, attendre l’arrivée de l’étiquette avant de pouvoir utiliser le temps et/ou la localisation, par exemple quelques millisecondes sur l’architecture cible d’une unité de contrôle télématique typique. Le module de connexion au réseau peut transmettre les informations à l’environnement d’exécution riche par un élément de communication choisi au moins parmi les éléments UART, SPI, CAN, DMA, AMBA, bus d’interconnect. Dans une variante de l’invention, le module de connexion au réseau est intégré dans environnement d’exécution en confiance du véhicule automobile. Cette solution coûte quelques dizaines d’euros supplémentaires par véhicule. Dispositif Selon un autre de ses aspects, l’invention porte sur un dispositif de communication sécurisée entre un système embarqué, notamment intégré dans un véhicule automobile, et un réseau externe, notamment un réseau de localisation, le système embarqué étant ou comportant au moins un environnement d’exécution riche relié à au moins une unité de contrôle électronique et destiné à recevoir des informations dudit réseau externe par le biais d’un module de connexion au réseau, le dispositif étant relié au moins à ce dernier et audit environnement d’exécution riche, et comportant un environnement d’exécution en confiance comprenant un moteur d’authentification contenant une clé privée générée au préalable, l’environnement d’exécution riche et ladite au moins une unité de contrôle électronique comportant une clé publique associée à ladite clé privée, le dispositif étant configuré de sorte que : lorsqu’une information en provenance du module de connexion au réseau est récupérée par l’environnement d’exécution en confiance, une étiquette d’authentification est générée par le moteur d’authentification de l’environnement d’exécution en confiance à l’aide de la clé privée contenue dans ce dernier, ladite étiquette d’authentification est transmise à l’environnement d’exécution riche, et lorsque ladite information est transmise à ladite au moins une unité de contrôle électronique reliée à l’environnement d’exécution riche, ladite étiquette d’authentification est transmise également et vérifiée grâce à ladite clé publique afin de sécuriser la communication de l’information. Dans un mode de réalisation préféré, le module de connexion au réseau est un sous-système GNSS, notamment un circuit intégré ou une puce externe. Les caractéristiques énoncées en relation avec le procédé s’appliquent au dispositif et vice-versa. Véhicule automobile Selon un autre de ses aspects, l’invention porte sur un véhicule automobile comprenant un groupe motopropulseur et au moins un dispositif de communication sécurisée selon l’invention. Les caractéristiques énoncées en relation avec le procédé s’appliquent au véhicule et vice-versa. L’invention pourra être mieux comprise à la lecture de la description détaillée qui va suivre, d’un exemple de mise en œuvre non limitatif de celle-ci, et à l’examen du dessin annexé, sur lequel FIG. 1 la FIG. 1 illustre un système de communication entre un système embarqué intégré dans un véhicule automobile et un réseau externe selon l’art antérieur, et FIG. 2 la FIG. 2 représente un exemple de mise en œuvre de l’invention. Description détaillée La FIG. 1 illustre la communication entre un système embarqué intégré dans un véhicule automobile et un réseau externe selon l’art antérieur. Le système embarqué est une unité de contrôle télématique, qui est constitué d’un module de connexion au réseau ayant la fonction de modem et de récepteur GNSS, et hébergeant un environnement d’exécution riche (REE) de type Linux/Android ou utilisant un système d’exploitation propriétaire. On suppose ici que l’attaquant peut prendre complètement le contrôle de l’environnement d’exécution riche et de son noyau, ou « kernel », par des attaques utilisant Internet comme vecteur. Le modem LTE n’est pas représenté ici, mais il est directement connecté à l’environnement d’exécution riche. Dans les architectures connues, le sous-système GNSS est un bloc IP hardware intégré au circuit intégré de l’unité de contrôle, ou bien un module hardware externe. Ce sous-système GNSS reçoit l’information de localisation et de temps depuis un réseau de satellites (1), généralement de plusieurs constellations telles que GPS, Glonass, Galileo. L’attaquant peut brouiller le signal radio émis par les satellites, et provoquer un déni de service, appelé DoS, ou jamming, ou corrompre le signal, ce qui correspond à du spoofing, pour envoyer une fausse information de localisation et de temps, bien que cette dernière attaque soit difficile en conditions réelles. Cette information sort ensuite du noyau du système d’exploitation, et est traitée par une chaîne de fusion de données et d’algorithmes permettant l’obtention d’une information de temps et de position propre (3). Elle est ensuite diffusée sur le réseau véhicule, par différents services selon le cas, tels que NTP, SOME/IP, gPTP, pour être reçue par différentes unités de contrôle électroniques (4), dont certaines en font une utilisation cryptographique. Un attaquant a dans ce cas deux leviers d’attaque. Il peut d’une part opérer une attaque physique à proximité du véhicule, par des moyens radio, permettant de rendre inopérant (jamming) ou corrompu (spoofing) le signal GNSS. D’autre part, une compromission à distance par Internet, via le modem LTE, par l’exploitation d’une vulnérabilité, par exemple dans les piles de communication 4G ou HTTP ou TLS, ou autre moyen, permet à l’attaquant de prendre le contrôle de l’environnement d’exécution riche, et de rendre inopérant ou erronée le signal de position et de temps émis aux autres unités de contrôle électroniques. On a représenté à la FIG. 2 un exemple de dispositif 1 selon l’invention adapté pour mettre en œuvre le procédé de communication sécurisée entre un système embarqué intégré dans un véhicule automobile et un réseau externe de localisation. Dans l’exemple considéré, le système embarqué est une unité de contrôle télématique comportant au moins un environnement d’exécution riche 2 relié à au moins une unité de contrôle électronique 3 distante et destiné à recevoir des informations dudit réseau externe par le biais d’un module de connexion au réseau 4, qui est un sous-système GNSS, par exemple un circuit intégré ou une puce externe. Le sous-système GNSS est relié à un environnement d’exécution en confiance 5 relié à l’environnement d’exécution riche et comportant un moteur d’authentification 6 contenant une clé privée générée au préalable, à laquelle seul l’environnement d’exécution en confiance a accès. L’environnement d’exécution riche et l’unité de contrôle électronique distante comportent une clé publique associée à la clé privée de l’environnement d’exécution en confiance. Dans cet exemple, le moteur d’authentification est un bloc logiciel ajouté dans l’environnement d’exécution en confiance, notamment sous la forme d’une application de confiance (TA). Comme visible à la FIG. 2 , lorsqu’une information de localisation et/ou de temps du réseau (1), en provenance du module de connexion au réseau, est récupérée par l’environnement d’exécution en confiance (2), une étiquette d’authentification est générée par le moteur d’authentification de l’environnement d’exécution en confiance à l’aide de la clé privée contenue dans ce dernier (5), par exemple de façon asynchrone et en utilisant les algorithmes RSA ou ECC. L’étiquette d’authentification est transmise à l’environnement d’exécution riche. Lorsque ladite information est transmise à l’unité de contrôle électronique reliée à l’environnement d’exécution riche (4), ladite étiquette d’authentification est transmise également et vérifiée grâce à ladite clé publique (6) afin de sécuriser la communication de l’information. Dans l’exemple illustré, au moins un capteur pluridimensionnel est relié à l’environnement d’exécution en confiance, par exemple 3D, 6D ou 9D, un accéléromètre et/ou un gyroscope, l’information en provenance du sous-système GNSS étant combinée à au moins une information pluridimensionnelle reçue de ce capteur. Dans ce cas, la fusion des informations pluridimensionnelles et de l’information en provenance du sous-système GNSS est réalisée par l’environnement d’exécution en confiance. L’unité de contrôle électronique reçoit de préférence, avec l’étiquette d’authentification, au moins une information précise de localisation et/ou de temps de l’environnement d’exécution riche et une information préliminaire de l’environnement d’exécution en confiance, utilisée pour la génération de l’étiquette d’authentification. Le module de connexion au réseau transmet par exemple les informations à l’environnement d’exécution riche par un élément de communication choisi au moins parmi les éléments UART, SPI, CAN, DMA, AMBA, bus d’interconnect. L’invention n’est pas limitée aux exemples qui viennent d’être décrits. En particulier, d’autres unités de contrôle électroniques peuvent être utilisées et être reliées au système embarqué mis en œuvre dans l’invention. L’invention peut être mise en œuvre dans des systèmes embarqués non intégrés à un véhicule automobile, dans des solutions dites « offboard ». L’invention peut s’appliquer à toute application où un système nécessite un niveau de confiance dans l’obtention d’un temps ou d’une localisation géographique par des technologies GNSS, dans les cas où ledit système peut être compromis par des cyberattaques parce qu’il héberge du logiciel non-digne de confiance ou parce qu’il est exposé à Internet. L’invention est également applicable à l’obtention de temps par des serveurs NTP, en hébergeant dans l’environnement d’exécution en confiance un client NTP. Procédé de communication sécurisée entre un système embarqué, notamment intégré dans un véhicule automobile, et un réseau externe, notamment un réseau de localisation, ledit système embarqué, notamment une unité de contrôle télématique, comportant au moins un environnement d’exécution riche (2) relié à au moins une unité de contrôle électronique (3) et destiné à recevoir des informations dudit réseau externe par le biais d’un module de connexion au réseau (4), ce dernier étant relié à un environnement d’exécution en confiance (5) relié au moins audit environnement d’exécution riche et comportant un moteur d’authentification (6) contenant une clé privée générée au préalable, l’environnement d’exécution riche et ladite au moins une unité de contrôle électronique comportant une clé publique associée à ladite clé privée, le procédé comportant au moins les étapes suivantes : lorsqu’une information en provenance du module de connexion au réseau est récupérée par l’environnement d’exécution en confiance, une étiquette d’authentification est générée par le moteur d’authentification de l’environnement d’exécution en confiance à l’aide de la clé privée contenue dans ce dernier, ladite étiquette d’authentification est transmise à l’environnement d’exécution riche, et lorsque ladite information est transmise à ladite au moins une unité de contrôle électronique reliée à l’environnement d’exécution riche, ladite étiquette d’authentification est transmise également et vérifiée grâce à ladite clé publique afin de sécuriser la communication de l’information. Procédé selon la revendication 1, dans lequel le module de connexion au réseau est un sous-système GNSS, notamment un circuit intégré ou une puce externe. Procédé selon la revendication 2, dans lequel l’information en provenance du module de connexion au réseau est une information de localisation et/ou de temps, calculée par le sous-système GNSS à partir des signaux radio qu’il reçoit. Procédé selon la revendication 2 ou 3, dans lequel au moins un capteur pluridimensionnel est relié à l’environnement d’exécution en confiance, notamment un accéléromètre et/ou un gyroscope, l’information en provenance du module de connexion au réseau étant combinée à au moins une information pluridimensionnelle reçue de ce capteur. Procédé selon la revendication précédente, dans lequel la fusion des informations pluridimensionnelles et de l’information en provenance du module de connexion au réseau est réalisée par l’environnement d’exécution en confiance. Procédé selon la revendication 4, dans lequel ladite au moins une unité de contrôle électronique reçoit, avec l’étiquette d’authentification, au moins une information précise de localisation et/ou de temps de l’environnement d’exécution riche et une information préliminaire de l’environnement d’exécution en confiance, utilisée pour la génération de l’étiquette d’authentification. Procédé selon l’une quelconque des revendications précédentes, dans lequel seul l’environnement d’exécution en confiance a accès à la clé privée. Procédé selon l’une quelconque des revendications précédentes, dans lequel le moteur d’authentification est un bloc logiciel ajouté dans l’environnement d’exécution en confiance, notamment sous la forme d’une application de confiance (TA), afin de réaliser l’authentification des informations émises par le module de connexion au réseau. Procédé selon l’une quelconque des revendications précédentes, dans lequel l’étiquette d’authentification est générée en utilisant les algorithmes RSA ou ECC. Procédé selon l’une quelconque des revendications précédentes, dans lequel ladite étiquette d’authentification est générée de façon asynchrone. Procédé selon l’une quelconque des revendications précédentes, dans lequel le module de connexion au réseau transmet les informations à l’environnement d’exécution riche par un élément de communication choisi au moins parmi les éléments UART, SPI, CAN, DMA, AMBA, bus d’interconnect. Dispositif (1) de communication sécurisée entre un système embarqué, notamment intégré dans un véhicule automobile, et un réseau externe, notamment un réseau de localisation, le système embarqué étant ou comportant au moins un environnement d’exécution riche (2) relié à au moins une unité de contrôle électronique (3) et destiné à recevoir des informations dudit réseau externe par le biais d’un module de connexion au réseau (4), le dispositif étant relié au moins à ce dernier et audit environnement d’exécution riche, et comportant un environnement d’exécution en confiance (5) comprenant un moteur d’authentification (6) contenant une clé privée générée au préalable, l’environnement d’exécution riche et ladite au moins une unité de contrôle électronique comportant une clé publique associée à ladite clé privée, le dispositif étant configuré de sorte que : lorsqu’une information en provenance du module de connexion au réseau est récupérée par l’environnement d’exécution en confiance, une étiquette d’authentification est générée par le moteur d’authentification de l’environnement d’exécution en confiance à l’aide de la clé privée contenue dans ce dernier, ladite étiquette d’authentification est transmise à l’environnement d’exécution riche, et lorsque ladite information est transmise à ladite au moins une unité de contrôle électronique reliée à l’environnement d’exécution riche, ladite étiquette d’authentification est transmise également et vérifiée grâce à ladite clé publique afin de sécuriser la communication de l’information. Dispositif selon la revendication précédente, dans lequel le module de connexion au réseau est un sous-système GNSS, notamment un circuit intégré ou une puce externe. Véhicule automobile comprenant un groupe motopropulseur et au moins un dispositif de communication sécurisée selon l’une quelconque des revendications 12 et 13.