FR 3097662 A1 20201225 FR 1906551 A 20190618 Description Titre de l'invention : Support mémoire, procédé d'installation de composants informatiques au sein d'un véhicule et procédé de pré- paration d'un support mémoire Domaine technique de l'invention 100011 La présente invention concerne de manière générale l'installation des composants in- formatiques au sein des véhicules, en particulier des véhicules automobiles. 100021 Elle trouve une application particulièrement avantageuse dans le cadre de mises à jour effectuées par un professionnel (revendeur ou garagiste), mais s'applique également pour une mise à jour effectuée par un particulier. 100031 Elle concerne plus particulièrement un support mémoire, un procédé d'installation de composants informatiques au sein d'un véhicule et un procédé de préparation d'un support mémoire. Etat de la technique [0004] On cherche dans certaines situations à installer des composants informatiques dans un équipement électronique équipant un véhicule. C'est notamment le cas lorsque l'on souhaite mettre à jour un logiciel exécuté au sein de l'équipement électronique ou des données manipulées par l'équipement. électronique. [0005] En pratique, plusieurs équipements électroniques peuvent être concernés par une campagne de mise à jour. Par ailleurs, au moment où il est décidé la mise à jour d'un véhicule, il est fréquent que plusieurs campagnes de mise à jour doivent être réalisées. Présentation de l'invention [0006] Dans ce contexte, la présente invention propose un support mémoire comprenant des moyens de communication aptes à établir une communication avec une unité de traitement d'un véhicule et une mémoire dans laquelle sont stockés : - au moins deux structures de données lisibles chacune par ladite unité de traitement lorsque ladite communication est établie ; - au moins deux composants informatiques respectivement associés aux deux structures de données ; - des métadonnées comprenant, pour au moins une (et éventuellement pour chacune) desdites structures de données, un condensat de référence associé à la structure de données concernée ; et - une signature des métadonnées. [0007] Ainsi, grâce à l'invention, les structures de données (qui correspondent par exemple respectivement à différentes campagnes de mise à jour du véhicule) peuvent être successivement traitées par l'unité de traitement du véhicule. Ceci permet une mise à jour 2 progressive du véhicule, avec une zone de mémoire tampon de taille moins importante (lorsqu'une telle zone de mémoire tampon est utilisée pour mémoriser chaque structure de données) puisque qu'une seule structure de donnée (correspondant à une campagne de mise à jour) sera traitée à la fois. [0008] Les métadonnées comprenant les condensats et la signature de ces métadonnécs permettent par ailleurs de s'assurer que les structures de données n'ont pas été altérées. [0009] D'autres caractéristiques avantageuses et non limitatives du procédé conforme à l'invention, prises individuellement ou selon toutes les combinaisons techniquement possibles, sont les suivantes : [0010] - au moins une desdites structures de données contient deux paquets de données res- pectivement destinés à deux équipements électroniques du véhicule ; [0011] - au moins une desdites structures comprend un paquet d'équipement associé à l'un desdits composants informatiques ; [0012] - le paquet d'équipement comprend un identifiant de véhicule. [0013] L'invention propose également un procédé d'installation de composants infor- matiques au sein d'un véhicule, comprenant les étapes suivantes : - établissement d'une communication entre une unité de traitement du véhicule et un support mémoire tel que proposé ci-dessus en utilisant lesdits moyens de communication ; - transfert des métadonnécs et de la signature des métadonnécs du support mémoire à l'unité de traitement via la communication établie ; - vérification de la signature des métadonnées sur la base des métadonnées transférées ; - pour chaque structure de données, transfert de la structure de données concernée du support mémoire à l'unité de traitement via la communication établie, détermination d'un condensat calculé sur la base de la structure de données reçue, et comparaison du condensat calculé et du condensat de référence associé à la structure de données concernée. [0014] La structure de données concernée peut comprendre un paquet d'équipement ; le procédé peut alors comprendre en outre, en cas de comparaison positive, une étape de transmission du paquet d'équipement à destination d'un équipement électronique du véhicule. [0015] L'équipement électronique peut alors commander la mémorisation, dans une mémoire non-volatile, d'un composant informatique associé au paquet d'équipement. [0016] Le procédé peut par ailleurs comprendre, en cas de comparaison positive, des étapes de transmission de chacun des deux paquets de données à l'équipement électronique auquel le paquet de données concerné est destiné. [0017] L'invention propose enfin un procédé de préparation d'un support mémoire tel que 3 proposé ci-dessus, comprenant les étapes suivantes : - stockage d'une pluralité de composants informatiques dans une module de stockage ; - réception d'un ensemble de données comprenant lesdites structures de données, lesdites métadonnées et ladite signature ; - lecture des composants informatiques associés auxdites structures de données dans le module de stockage ; - écriture, dans la mémoire du support mémoire, des données dudit ensemble et desdits composants informatiques lus. [0018] Ce procédé peut comprendre une étape de réception d'au moins un composant in- formatique de ladite pluralité indépendamment de l'étape de réception de l'ensemble de données. [0019] Bien entendu, les différentes caractéristiques, variantes et formes de réalisation de l'invention peuvent être associées les unes avec les autres selon diverses combinaisons dans la mesure où elles ne sont pas incompatibles ou exclusives les unes des autres. Description détaillée de l'invention [0020] La description qui va suivre en regard des dessins annexés, donnés à titre d'exemples non limitatifs, fera bien comprendre en quoi consiste l'invention et comment elle peut être réalisée. [0021] Sur les dessins annexés : [0022] [fig.1] représente schématiquement un système dans lequel peut être mise en oeuvre l' invention ; [0023] [fig.21 représente un support mémoire du système de la figure 1 ; [0024] [fig.3] présente un exemple d'organisation de données au sein d'une mémoire du support mémoire de la figure 2 ; [0025] [fig.4] présente un exemple d'architecture utilisée pour un paquet de mise à jour mémorisé dans cette mémoire ; [0026] [fig.51 représente schématiquement un exemple de procédé envisageable pour la pré- paration d'un paquet de mise à jour à enregistrer au sein du support mémoire de la figure 2 ; [0027] [fig.6] présente schématiquement un procédé de préparation du support mémoire de la figure 2 avec une organisation des données selon la figure 3 ; [0028] [fig.7] présente schématiquement un exemple de procédé d'installation de composants informatiques au sein d'un véhicule de la figure 1 ; et [0029] [fig.8] présente un exemple de procédé d'installation de composants informatiques au moyen d'un paquet de mise à jour. [0030] Le système de la figure 1 comprend un véhicule 2 (par exemple un véhicule au- tomobile) et un support mémoire 20, tel qu'une clé connectable par bus universel série (ou clé USB pour "Universal Serial Bus"), ou une carte mémoire (par exemple une carte SD, SD signifiant "Secure Digital"), ou tout autre dispositif de mémoire externe (amovible) localement connectable sur le véhicule 2. [0031] Le véhicule 2 comprend une unité de traitement 4, une première unité électronique de commande 6, une passerelle 8 et une seconde unité électronique de commande 10. [0032] On a représenté sur la figure 1 les éléments du véhicule 2 utiles à la compréhension de l'invention, mais le véhicule 2 comprend bien entendu en pratique d'autres éléments, notamment d'autres unités électroniques dc commande ou calculateurs. [0033] Les équipements électroniques mentionnés ci-dessus (unité de traitement 4, première unité électronique de commande 6, passerelle 8 et seconde unité électronique de commande 10) peuvent chacun être réalisés en pratique sous forme d'une architecture à microprocesseur ; dans ce contexte notamment, chacun de ces équipements électroniques comprend un processeur et au moins une mémoire (par exemple une mémoire vive et/ou une mémoire non-volatile). [0034] L'unité de traitement 4 peut elle-même être mise en oeuvre en pratique au moyen d'une unité électronique de commande, ayant éventuellement d'autres fonctionnalités que celles décrites ci-dessous. [0035] Comme représenté schématiquement en figure 1, l'unité de traitement 4 est reliée à la première unité électronique de commande 6 et à la passerelle 8 afin de pouvoir échanger des données avec ces différents équipements électroniques. L'unité de traitement 4, l'unité électronique de commande 6 et la passerelle 8 sont par exemple pour ce faire connectée à un (même) réseau informatique embarqué (non représenté), par exemple un bus CAN (pour "Controller Area Network"). [0036] La passerelle 8 est par ailleurs reliée à la seconde unité électronique de commande 10, par exemple au moyen d'un bus dédié. [0037] Le véhicule 2 comprend en outre un connecteur 12 relié à l'unité de traitement 4 pour connexion au support mémoire 20, comme expliqué ci-dessous. [0038] Comme montré sur la figure 2, le support mémoire 20 comprend une mémoire 26 (par exemple une mémoire non-volatile réinscriptible) et des moyens de commu- nication 22, 24 aptes à établir une communication avec l'unité de traitement 4. [0039] Ici, ces moyens de communication comprennent un contrôleur 24 et un connecteur 22 (par exemple un connecteur USB) enfichable dans le connecteur 12 du véhicule 2. [0040] Lorsque le connecteur 22 du support mémoire 20 est enfiché dans le connecteur 12 relié à l'unité de traitement 4, le support mémoire 20 est alimenté électriquement et une communication s'établit entre l'unité de traitement 4 et le contrôleur 24. [0041] Une fois cette communication établie, l'unité de traitement 4 peut demander la lecture de données mémorisées dans la mémoire 26 : le contrôleur 24 lit dans la mémoire 26 les données demandées et transmet les données lues à l'unité de traitement 4 via la communication établie. [0042] De même, l'unité de traitement 4 peut demander l'écriture de données dans la mémoire 26 (à un emplacement particulier) : les données à écrire (et l'emplacement choisi) sont transmises de l'unité de traitement 4 au contrôleur 24 via la communication établie et le contrôleur 24 écrit ces données transmises dans la mémoire 26 (à l'emplacement choisi). [0043] On utilise dans la suite diverses signatures numériques (en anglais "digital signatures signature" dans la suite toute signature numérique. [0044] Pour chaque type de signature utilisée, une infrastructure à clé publique (ou PKI pour "Public Key Infrastructure") est mise en place. Dans une telle infrastructure à clé publique, on associe classiquement une clé publique (destinée à être distribuée) et une clé privée (tenue secrète par l'entité signataire). [0045] Dans un tel contexte, un ensemble de données peut être signé par application, à cet ensemble de données, d'un algorithme cryptographique de signature (ici de type RSA) utilisant la clé privée concernée ; la signature peut alors être vérifiée au moyen d'un algorithme cryptographique de vérification de signature associé (ici donc également de type RSA), en utilisant la clé publique associée à la clé privée précitée. [0046] La figure 3 présente un exemple d'organisation des données mémorisées au sein de la mémoire 26. [0047] Ces données comprennent une pluralité de paquets de mise à jour DPACK1, DPACK2, DPACK3. [0048] Comme démit en détail plus bas, chaque paquet de mise à jour DPACK1, DPACK2, DPACK3 est destiné à être transmis à l'unité de traitement 4 du véhicule 2 en vue de l'installation d'au moins un composant informatique au sein d'une unité électronique de commande (par exemple parmi l'unité de traitement 4 elle-même, la première unité électronique de commande 6 et la seconde unité électronique de commande 10). [0049] En pratique, le composant informatique à installer peut être inclus dans le paquet de mise à jour DPACK1, DPACK2, DPACK3 visant l'installation de ce composant informatique (comme c'est le cas dans l'exemple décrit ci-dessous en référence à la figure 4). En variante, le composant informatique COMP pourrait toutefois être mémorisé dans la mémoire 26 séparément du paquet de mise à jour associé, comme schématiquement représenté en pointillés en figure 3. [0050] Les données mémorisées dans la mémoire 26 comprennent également : [0051] - des métadonnées INDEX relatives aux paquets de mise à jour DPACK1, DPACK2, DPACK3 et, ici, à d'autres éléments décrits ci-dessous (outils d'orchestration TLS, données d'interface IHM, blocs de données (l'introduction PREDATIL PREDAT2, PREDAT3) ; [0052] - une signature SIG(INDEX) de ces métadonnées INDEX; 6 [0053] - des outils d'orchestration TLS (par exemple des fichiers exécutables ou des pilotes) utilisables éventuellement par l'unité de traitement 4 pour traiter les paquets de mise à jour DPACK1, DPACK2, DPACK3; [0054] - des données d'interface II-1M utilisables éventuellement par l'unité de traitement 4 pour affichage sur une interface utilisateur (non représentée) du véhicule 2. [0055] L'orchestration effectuée par l'outil d'orchestration TLS peut comprendre par exemple le séquencement et/ou l'ordonnancement des opérations à mettre en oeuvre pour l'installation des composants, ainsi qu'éventuellement la gestion des conditions d'exécution et/ou les erreurs apparues au cours de l'exécution et/ou les échanges utilisateur (en utilisant le cas échéant les données d'interface IHM). [0056] Les métadonnées INDEX comprennent par exemple un descriptif (tel qu'une liste) des paquets de mise à jour DPACK1, DPACK2, DPACK3 et, pour chaque paquet de mise à jour DPACK1, DPACK2, DPACK3 mémorisé dans la mémoire 26, un condensat de référence associé au paquet de mise à jour DPACK1, DPACK2, DPACK3 concerné (ce condensat de référence étant obtenu sur la base du paquet de mise à jour concerné, par exemple par application d'une fonction de hachage). [0057] La mémoire 26 peut en outre mémoriser en pratique des blocs de données d'introduction PREDAT1, PREDAT2, PREDAT3 associés respectivement aux différents paquets de mise à jour DPACK1, DPACK2, DPACK3. Un bloc de données d'introduction PREDAT1, PREDAT2, PREDAT3 associé à un paquet de mise à jour DPACK1, DPACK2, DPACK3 donné contient par exemple une adresse de mémorisation de ce paquet de mise à jour donné dans la mémoire 26 et/ou des données d'interface utilisables par l'unité de traitement 4 pour affichage sur une interface utilisateur (non représentée) du véhicule 2 spécifiquement lorsque l'unité de traitement 4 traite le paquet de mise à jour donné. [0058] On décrit à présent en référence à la figure 4 un exemple d'architecture utilisée pour un paquet de mise à jour DPACK. Chacun des paquets de mise à jour DPACK1, DPACK2, DPACK3 déjà mentionnés est construit selon cette architecture afin de pouvoir être traité par l'unité de traitement 4. [0059] Comme visible sur la figure 4, cette architecture est basée sur une structure arbo- rescente à plusieurs niveaux : - le paquet de mise à jour DPACK comprend un ou plusieurs paquet(s) d'équipement ECUPACK1, ECUPACK2, ECUPACKn relatif(s) (chacun) à un équipement électronique du véhicule 2 ; - chaque paquet d'équipement ECUPACK comprend des données relatives à un ou plusieurs composant(s) informatique(s) COMP1, COMP2, COMPi destiné(s) à un équipement électronique particulier. [0060] Comme déjà indiqué, les composants informatiques COMP1, COMP2, COMPi 7 peuvent eux-mêmes être compris dans le paquet d'équipement ECUPACK concerné (c'est-à-dire ici encapsulés au sein de la structure arborescente) comme représenté en figure 4, ou, en variante, être situés (en pratique : mémorisés) en dehors du paquet de mise à jour DPACK. [0061] Sont utilisés en particulier dans le cadre de la description du paquet dc mise à jour DPACK : - un certificat racine ROOT.cert contenant des métadonnées ROOT.md et une clé publique ROOT.Kpub associée à une clé privée ROOT.Kpriv ; - un certificat d'autorité CA.cert contenant des métadonnées CA.md, une clé publique CA.Kpub et une signature CA.sig ; - un certificat constructeur R.ccrt contenant des métadonnées R.md, une clé publique R.Kpub et une signature R.sig ; - une clé publique BK.Kpub associée à une clé privée BK.Kpriv. [0062] Une clé privée CA.Kpriv est associée à la clé publique CA.Kpub. [0063] De même, une clé privée R.Kpriv est associée à la clé publique R.Kpub. [0064] La signature CA.sig du certificat d'autorité CA.cert est obtenue en appliquant un al- gorithme cryptographique de signature utilisant la clé privée ROOT.Kpriv à l'ensemble formé des métadonnées CA.md et de la clé publique CA.Kpub (cette opération étant réalisée par exemple par une autorité de certification). [0065] La signature R.sig du certificat constructeur R.oert est quant à elle obtenue en ap- pliquant un algorithme cryptographique de signature utilisant la clé privée CA.Kpriv l'ensemble formé des métadonnées R.md et de la clé publique R.Kpub (cette opération pouvant elle aussi être réalisée par l'autorité de certification précitée). [0066] On décrit à présent en détail les différentes structures de données représentée à la figure 4. [0067] Chaque composant informatique COMP à installer comprend : - un contenu CONTEN comprenant les données à installer (en pratique à mémoriser) dans l'équipement électronique concerné ; - un manifeste COMPIND, contenant notamment un condensat H(CONTEN) du contenu à installer et éventuellement un descriptif du composant informatique, par exemple un descriptif des fonctions mises à jour par ce composant ; - une signature SIG(COMPIND) du manifeste COMP1ND. [0068] Ces données à installer peuvent constituer un logiciel ou une partie d'un logiciel (par exemple une mise à jour du logiciel). Ce logiciel ou cette partie de logiciel est alors conçu(e) pour être exécuté(e) au moins en partie par un processeur de l'équipement électronique concerné. En variante, ces données à installer peuvent être des données à mémoriser (par exemple des données cartographiques) pour manipulation ultérieure par un processeur de l'équipement électronique concerné. 8 [0069] Le condcnsat H(CONTEN) est obtenu par application d'une fonction de hachage (par exemple de type SHA-256) au contenu CONTEN. [0070] La signature SIG(COMPIND) est obtenue par application au manifeste COMIND d'un algorithme cryptographique de signature utilisant la clé privée BK.Kpriv. [0071] Ces opérations sont par exemple effectuées par un organisme de certification du contenu CONTEN (par exemple du logiciel) concerné. [0072] Chaque paquet d'équipement ECUPACK comprend ici : - un ou plusieurs composant( s) informatique(s) COMP1, COMP2, COMPi tel que décrit ci-dessus ; - un manifeste ECUPACKIND comprenant un condensat H(COMP1), H(COMP2), H(COMPi) pour chacun des composants informatiques COMP1, COMP2, COMPi contenus dans le paquet d'équipement ECUPACK, ainsi qu'éventuellement un identifiant VIN de véhicule et/ou un descriptif des composants informatiques COMP1, COMP2, COMPi contenus dans le paquet ; - une signature SIG(ECUPACKIND) du manifeste ECUPACKIND. [0073] L'inclusion de l'identifiant VIN dans le paquet d'équipement ECUPACK, comme mentionné ci-dessus, permet d'assurer que le composant informatique installé dans l'équipement électronique (par exemple un calculateur du véhicule) est bien le composant attribué à ce véhicule. En effet, un composant pourrait très bien convenir à une multitude de véhicules d'un même type, offrant la possibilité à un utilisateur par exemple de remplacer un calculateur de son véhicule par un calculateur d'un autre véhicule de même type. L'inclusion de l'identifiant VIN dans le paquet d'équipement ECUPACK permet d'empêcher cette manipulation. [0074] En variante toutefois, l'identifiant VIN de véhicule pourrait être placée au sein du manifeste DPACKIND décrit plus bas. Dans ce cas, on peut envisager de ne transmettre (au moyen de l'unité de traitement 4) le paquet d'équipement ECUPACK l'équipement électronique concerné qu'en cas de comparaison positive entre l'identifiant VIN reçu au sein du manifeste DPACKIND et l'identifiant du véhicule 2 tel que mémorisé (ici au sein de l'unité de traitement 4). [0075] Selon une autre variante, l'identifiant VIN peut être placé à la fois dans le manifeste DPACKIND et dans le manifeste ECUPACKIND. [0076] Selon une autre variante encore, l'identifiant VIN peut n'être placé dans aucun de deux manifestes DPACKIND, ECUPACKIND, en particulier pour un composant informatique compatible à tout véhicule, comme par exemple un composant informatique comprenant des données cartographiques d'un système de navigation. [0077] Ici, l'identifiant VIN de véhicule est un nombre associé de manière unique à un véhicule, couramment désigné sous l'appellation VIN (pour "Vehiele Identification Number"). 9 [0078] Les condensats H(COMP1), H(COMP2), H(COMPi) sont respectivement obtenus par application d'une fonction de hachage (par exemple de type SHA-256) aux données constituant le composant informatique COMP1, COMP2, COMPi concerné, par exemple lors de la définition du paquet d'équipement ECUPACK (en fonction des besoins de l'équipement concerné, notamment des besoins de mise à jour de cet équipement). [0079] La signature SIG(ECUPACKIND) est obtenue par application au manifeste ECUPACKIND d'un algorithme cryptographique de signature utilisant la clé privée R.Kpriv (associée au certificat constructeur R.cert). [0080] Ces opérations sont par exemple effectuées par le constructeur automobile (ou pour le compte du constructeur automobile) lorsque sont définis les composants informatiques à installer pour l'équipement électronique concerné dans un véhicule donné (identifié par l'identifiant VIN). [0081] En pratique, la signature SIG(ECUPACKIND) est par exemple contenue dans un champ dédié du paquet d'équipement ECUPACK, par exemple un champ au format cms (pour "Cryptographie Message Syntax"). Dans ce cas, ce champ peut comprendre la signature SIG(ECUPACKIND), le certificat d'autorité CA.cert et le certificat constructeur R.cert. [0082] Le paquet de mise à jour DPACK comprend : - un ou plusieurs paquet(s) d'équipement ECUPACK1, ECUPACK2, ECUPACKn tel(s) que décrit(s) ci-dessus ; - un manifeste DPACKIND comprenant notamment un condensat H(ECUPACK1), H(ECUPACK2), H(ECUPACKn) pour chacun des paquets d'équipement ECUPACK1, ECUPACK2, ECUPACKn contenus dans le paquet de mise à jour DPACK, ainsi qu'éventuellement un descriptif des paquets d'équipement ECUPACK1, ECUPACK2, ECUPACKn contenus dans le paquet de mise à jour DPACK (avec par exemple une indication, pour chaque paquet d'équipement ECUPACK1, ECUPACK2, ECUPACKn, de l'équipement électronique destinataire du paquet (l'équipement concerné) ; - une signature SIG(DPACKIND) du manifeste DPACKIND. [0083] Les condensats H(ECUPACK1), H(ECUPACK2), H(ECUPACKn) sont respectivement obtenus par application d'une fonction de hachage (par exemple de type SHA-256) au paquet d'équipement ECUPACK2, ECUPACK2, ECUPACKn concerné, par exemple lors de la définition du paquet de mise à jour DPACK (après définition des équipements électroniques visés et des besoins respectifs de chacun de ces équipements). [0084] La signature SIG(DPACKIND) est obtenue par application au manifeste DPACKIND d'un algorithme cryptographique de signature utilisant la clé privée R.Kpriv (associée au certificat constructeur R.cert). [0085] Ces opérations sont par exemple effectuées par le constructeur automobile (ou pour le compte du constructeur automobile) lorsque sont définis les équipements électroniques concernés et les composants informatiques à installer dans ces équipements électroniques. [0086] En pratique, la signature SIG(DPACKIND) est par exemple contenue dans un champ dédié du paquet de mise à jour DPACK, par exemple un champ au format cms (pour " Cryprographic Message Syntax"). Dans ce cas, cc champ peut comprendre la signature SIG(DPACKIND), le certificat d'autorité CA.cert et le certificat constructeur R.cert. [0087] On remarque que, dans l'architecture qui vient d'être décrite, chacun des composants informatiques COMP1, COMP2, COMPi est indépendant du véhicule 2 visé par l'installation (et peut par exemple être utilisé pour une flotte de véhicules). Les paquets d'équipement ECUPACK1, ECUPACK2, ECUPACKn (et par conséquent le paquet de mise à jour DPACK) peuvent en revanche être spécifiquement conçus pour le véhicule 2 (en particulier lorsque le manifeste EUCPACKIND contient l'identifiant VIN de véhicule). [0088] La figure 5 représente schématiquement un exemple de procédé envisageable pour la préparation d'un paquet de mise à jour DPACK à enregistrer au sein du support mémoire 20. [0089] L'utilisation de ce procédé est particulièrement intéressante lorsque les besoins de mise à jour du véhicule 2 sont définis au sein d'une première structure C (typiquement un établissement du constructeur automobile), mais doivent être mises en oeuvre au moyen du support mémoire 20 au sein d'une seconde structure G (typiquement un revendeur ou un garage) où de nombreux véhicules sont susceptibles d'être mis à jour. [0090] Le procédé de la figure 5 comprend une étape E0 au cours de laquelle des composants informatiques COMP1, COMP2, COMPi, COMPx sont transmis de la première structure C à la seconde structure G, où ces composants informatiques COMP1, COMP2, COMPi, COMPx sont mémorisés dans un module de stockage S de la seconde structure G (par exemple un disque dur situé dans les locaux de la seconde structure G). Cette transmission est par exemple réalisée via un ou plusieurs réseau(x) informatique(s), par exemple via un réseau étendu tel qu'Intemet, et peut être chiffrée [0091] Les composants informatiques COMP1, COMP2, COMPi, COMPx ainsi transmis sont divers composants informatiques susceptibles d'être utilisés lors de mises à jour de véhicules au sein de la seconde structure G. Comme déjà indiqué, ces composants informatiques COMPi, COMP2, COMPi, COMPx ne sont pas conçus pour un véhicule particulier, mais chacun de ces composants informatiques COMP1, COMP2, COMPi, COMPx peut au contraire être utilisé pour une flotte de véhicules. [0092] La transmission de l'étape EO peut ainsi en pratique être réalisée à l'avance, 11 c'est-à-dire avant une éventuelle visite d'un véhicule au sein de la seconde structure G (revendeur ou garage). Ceci permet de limiter le volume des téléchargements à effectuer au moment où le véhicule est présent au sein de la seconde structure G (voir la transmission de l'étape El 0 décrite plus loin). La transmission de l'étape E0 peut ainsi être éventuellement effectuée à des moments où la bande passante disponible est importante, par exemple de nuit. [0093] On remarque par ailleurs que, bien que l'étape E0 soit représentée sous forme d'une seule étape, les différents composants informatiques COMP1, COMP2, COMPi, COMPx peuvent être transmis séparément, à des moments différents et d'ailleurs indépendamment des autres étapes décrites à présent (c'est-à-dire pas nécessairement avant l'étape E2). [0094] Le procédé de la figure 5 comprend également une étape E2 de définition des besoins de mise à jour d'un véhicule particulier, ici le véhicule 2, c'est-à-dire une étape de sélection de composants informatiques COMP1, COMP2, COMPi à installer dans ce véhicule 2. [0095] Les condensats H(COMP1), H(COMP2), H(COMPi) respectivement associés à ces composants informatiques COMP1, COMP2, COMPi peuvent ainsi être préparés (ou lus en mémoire). [0096] Le manifeste ECUPACKIND du paquet d'équipement ECUPACK concerné peut dès lors être construit à l'étape E4, en combinant notamment les condensats H(COMP1), H(COMP2), H(COMPi) précités et l'identifiant VIN de véhicule pour le véhicule 2 dans lequel les composants informatiques COMP1, COMP2, COMPi doivent être installés. [0097] Le procédé comprend alors une étape E6 au cours de laquelle la signature SIG(ECUPACKIND) est obtenue par application au manifeste ECUPACKIND d'un algorithme cryptographique de signature utilisant la clé privée R.Kpriv (associée au certificat constructeur R.cert). [0098] Le paquet d'équipement ECUPACK peut ainsi être construit en combinant le manifeste ECUPACKIND et la signature SIG(ECUPACKIND), ainsi qu'éventuellement les composants informatiques COMPi, COMP2, COMPi eux-mêmes (même si ces composants informatiques COMPi, COMP2, COMPi ne seront finalement pas transmis lors de l'étape EIO comme expliqué plus bas). [0099] Le procédé de la figure 5 comprend ensuite une étape E8 de préparation du paquet de mise à jour DPACK sur la base notamment du paquet d'équipement ECUPACK construit à l'étape E8, d'un manifeste DPACKIND comprenant un condensat pour chaque paquet d'équipement compris dans le paquet de mise à jour DPACK, et d'une signature SIG(DPACKIND), conformément à ce qui a été décrit ci-dessus en référence à la figure 4. 12 [0100] Le procédé de la figure 5 comprend alors une étape El 0 de transmission du paquet de mise à jour DPACK, sans les composants informatiques COMP1, COMP2, COMPn, de la première structure C à la seconde structure G. Cette transmission est par exemple réalisée via un ou plusieurs réseau(x) informatique( s), par exemple via un réseau étendu tel qu'Internet, et peut être chiffrée. [0101] Dans les modes de réalisation tels que celui de la figure 4 où les composants infor- matiques sont intégrés au paquet de mise à jour DPACK, les composants informatiques sont ainsi supprimés du paquet de mise à jour DPACK avant transmission à la seconde structure G. [0102] Dans tous les cas, on évite à cette étape El 0 la transmission des composants infor- matiques COMP1, COMP2, COMPn. On remarque que ces composants informatiques COMP1, COMP2, COMPn ont en revanche été transmis à l'étape E0, mais une fois pour toutes ; ainsi, un composant informatique donné COMPi est transmis à l'étape E0 et il donc n'est plus nécessaire de transmettre ce composant informatique COMPi donné à chaque fois qu'il doit être utilisé pour mettre à jour un véhicule. [0103] Le paquet de mise à jour DPACK est par conséquent reçu au sein de la seconde structure G à l'étape EU, sans les composants informatiques COMP1, COMP2, COMPi. [0104] Les composants informatiques COMP1, COMP2, COMPi sont alors lus dans le module de stockage S à l'étape E14. [0105] En pratique, un ordinateur présent dans la seconde structure G consulte par exemple, pour chaque paquet d'équipement ECUPACK, le descriptif des composants informatiques COMPI, COMP2, COMPi visés dans ce paquet d'équipement ECUPACK (ce descriptif pouvant faire partie du manifeste ECUPACKIND comme expliqué plus haut) et lit sur cette base les composants informatiques COMP1, COMP2, COMPi dans le module de stockage S. [0106] Selon une variante envisageable, des données désignant ces composants infor- matiques COMPi, COMP2, COMPi peuvent être annexées à la transmission effectuée lors de l'étape E10. Ainsi, à réception du paquet de mise à jour DPACK sans les composants informatiques COMPI, COMP2, COMPi, un ordinateur présent dans la seconde structure G peut utiliser ces données annexées afin de déterminer quels composants informatiques COMPI, COMP2, COMPi doivent être lus dans le module de stockage S. [0107] Le paquet de mise à jour DPACK incluant les composants informatiques COMPi, COMP2, COMPi peut ainsi être reconstruit à l'étape E16. [0108] Le paquet de mise à jour DPACK et les composants informatiques COMPI, COMP2, COMPi (intégrés dans le paquet de mise à jour DPACK dans le cas du mode de réa- lisation de la figure 4) peuvent ainsi être inscrits dans la mémoire 26 du support 13 mémoire 20 à l'étape El 8. Pour ce faire, un opérateur connecte par exemple le support mémoire 20 sur l'ordinateur susmentionné (présent dans la seconde structure G) et lance (au moyen de cet ordinateur) une opération d'écriture du paquet de mise à jour DPACK (reçu à l'étape El 2 sans composant informatique) et des composants informatiques (lus dans le module de stockage S à l'étape E14) au sein de la mémoire 26. [0109] D'autres données peuvent en pratique être inscrites lors de l'étape E18, comme décrit ci-après. [0110] La figure 6 présente schématiquement un procédé de préparation du support mémoire 20 avec une organisation des données telle que proposée à la figure 3 décrite plus haut. [0111] Un tel procédé peut être mis en oeuvre au sein de la seconde structure G (revendeur ou garage) introduite dans le cadre de la figure 5, par exemple au moyen d'un ordinateur situé dans cette seconde structure G et auquel le support mémoire 20 est connecté. [0112] En variante, ce procédé pourrait être mis en oeuvre sur plusieurs sites selon l'étape concernée, par exemple sur un site de conception du constructeur automobile pour les étapes E20 à E26 et sur un site de production (ou en variante chez un particulier) pour l'étape E28. [0113] Le procédé de la figure 6 débute par une étape E20 d'obtention d'une pluralité de paquets de mise à jour DPACK1, DPACK2, DPACK3. En pratique, chaque paquet de mise à jour DPACK1 ; DPACK2, DPACK3 correspond par exemple à une campagne de mise à jour du véhicule 2 et peut ainsi contenir des composants informatiques relatifs respectivement à divers équipements électroniques du véhicule 2 (comme c'est le cas pour le paquet de mise à jour DPACK de la figure 4). [0114] Dans le cas où le procédé est mis en oeuvre au sein de la seconde structure G, un procédé tel que celui décrit ci-dessus en référence à la figure 5 peut être utilisé pour obtenir au moins un paquet de mise à jour DPACK1 ; DPACK2 ; DPACK3 et l'étape E20 correspond alors à l'étape E16 décrite plus haut, où est reconstruit le paquet de mise à jour à partir de données reçues à l'étape E12 et de composants informatiques lus dans un module de stockage local S à l'étape E14. [0115] Dans d'autres cas (par exemple lorsque l'étape E20 est effectuée sur un site de conception), on utilise par exemple des étapes similaires aux étapes E2 à E8 décrites ci-dessus pour obtenir au moins un paquet de mise à jour DPACK1 ; DPACK2 ; DPACK3. [0116] L'étape E20 peut inclure en outre la préparation des blocs de données d'introduction PREDAT1, PREDAT2, PREDAT3 respectivement associés aux paquets de mise à jour DPACK1, DPACK2, DPACK3 comme décrit plus haut. [0117] Le procédé de la figure 6 comprend ensuite une étape E22 de préparation d'éléments annexes, comme par exemple les outils d'orchestration TLS et les données d'interface 14 IHM. [0118] Le procédé de la figure 6 comprend alors une étape E24 de préparation des me- tadonnées INDEX sur la base des différents paquets de mise à jour DPACK1, DPACK2, DPACK3 (ainsi que sur la base des autres éléments contenus dans la mémoire 26 dont on veut s'assurer de l'intégrité et de l'authenticité, notamment ici les données d'introduction PREDAT1, PREDAT2, PREDAT3, les outils d'orchestration TLS et les données d'interface IHM). [0119] Cette étape E24 comprend notamment, pour chaque paquet de mise à jour DPACK1 ; DPACK2 ; DPACK3, le calcul d'un condensat (dénommé "condensai de référence" dans la suite) par application d'une fonction de hachage (par exemple de type SHA256) au paquet de mise à jour DPACK1 ; DPACK2 ; DPACK3 concerné. Le cas échéant, l'étape E24 comprend en outre le calcul d'un condensat pour chacun des autres éléments précités, ici les données d'introduction PREDAT1, PREDAT2, PREDAT3, les outils d'orchestration TLS et les données d'interface IHM. [0120] Les condensats ainsi calculés sont intégrés dans les métadonnées INDEX. [0121] Le procédé de la figure 6 comprend enfin une étape E26 de production de la signature SIG(INDEX) par application aux rnétadonnées INDEX d'un algorithme cryptographique de signature utilisant une clé privée Kpriv. Dans certains modes de réalisation, cette clé privée peut être la clé privée R.Kpriv déjà mentionnée (et associée au certificat constructeur R.cert). Dans ce cas, l'étape E26 notamment est de préférence réalisée au sein de la première structure C. Une clé privée dédiée peut toutefois être utilisée en variante (notamment lorsque l'étape E26 est réalisée en dehors de la première structure C, par exemple lorsque cette étape E26 notamment est réalisé au sein de la seconde structure G comme envisagé ci-dessous). [0122] Le procédé de la figure 6 peut ainsi s'achever par l'écriture des données obtenues et préparées au cours des étapes E20 à E26 (comme cela vient d'être (lécrit) au sein de la mémoire 26 du support mémoire 20, ce qui permet d'obtenir une mémoire 26 organisée comme représenté en figure 3 et décrit plus haut. [0123] On peut remarquer que la mémoire 26 mémorise une pluralité de paquets de mise à jour DPACK1, DPACK2, DPACK3 qui peuvent par exemple correspondre en pratique à plusieurs campagnes de mise à jour du véhicule 2. [0124] Lorsque le procédé est mis en oeuvre au sein de la seconde structure G au moyen de l'ordinateur situé dans cette seconde structure G, cet ordinateur a par exemple mis en oeuvre les étapes E22 à E26 et peut commander l'écriture des données dans la mémoire 26 à l'étape E28. [0125] Selon une autre possibilité de réalisation, lorsque les étapes E20 à E26 sont mises en oeuvre au sein d'un site du constructeur, les données obtenues et préparées au cours des étapes E20 à E26 peuvent être téléchargées sur un ordinateur personnel situé chez un particulier et écrites dans la mémoire 26 du support mémoire 20 connecté à cet ordinateur personnel. [0126] La figure 7 présente schématiquement un exemple de procédé d'installation de composants informatiques au sein du véhicule 2. [0127] Ce procédé débute à l'étape E30 par l'insertion du support mémoire 20 dans le connecteur 12 équipant le véhicule 2 comme décrit plus haut en référence à la figure 1. Cette étape d'insertion peut être effectuée en pratique par un opérateur ou par le propriétaire du véhicule 2. [0128] Comme déjà expliqué, une communication s'établit alors entre l'unité de traitement 4 et le contrôleur 24 de sorte que l'unité de traitement 4 peut notamment lire des données dans la mémoire 26 du support mémoire 20. [0129] L'unité de traitement 4 peut ainsi lire à l'étape E32 les rnétadonnécs INDEX et la signature SIG(INDEX) mémorisées dans la mémoire 26 (ainsi qu'éventuellement les outils d'orchestration TLS et/ou les données d'interface IHM). Les métadonnécs INDEX et la signature SIG(TNDEX) sont ainsi transférées (en pratique recopiées) du support mémoire 20 vers l'unité de traitement 4. [0130] L'unité de traitement 4 peut alors vérifier à l'étape E34 que la signature SIG(NDEX) correspond effectivement aux rnétadonnées INDEX, en pratique en appliquant aux métadonnées INDEX et à la signature SIG(INDEX) un algorithme cryptographique de vérification de signature utilisant la clé publique Kpub associée à la clé privée Kpriv susmentionnée. La clé publique Kpub est par exemple mémorisée dans l'unité de traitement 4 lors de la fabrication du véhicule 2 (ou en variante après téléchargement dans l'unité de traitement 4 au moyen d'un module télématique non représenté). [0131] Si la signature SIG(INDEX) n'est pas correctement vérifiée, il est mis fin au procédé de la figure 7 sans installation de composant informatique. [0132] Lorsque la signature SIG(INDEX) est correctement vérifiée, le procédé de la figure? entre dans une boucle pour traitement successif des différents paquets de mise à jour DPACK1, DPACK2, DPACK3, le paquet de mise à jour en cours de traitement étant désigné DPACKn dans la suite. [0133] On remarque que le traitement qui suit (en particulier certaines au moins des étapes E36 à E48) peut éventuellement être mis en oeuvre en utilisant les outils d'orchestration TLS, par exemple en suivant un ordonnancement (ou séquencement) des blocs de données d'introduction PREDATI, PREDAT2, PREDAT3 et/ou des paquets de mise à jour DPACKI, DPACK2, DPACK3 défini par les outils d'orchestration TLS et/ou en mettant en oeuvre des actions supplémentaires définies par les outils d'orchestration TLS et/ou par exécution (par l'unité de traitement 4) de données exécutables contenues dans les outils d'orchestration TLS. [0134] L'unité de traitement 4 lit à l'étape E36 (dans la mémoire 26) le bloc de données 16 d'introduction PREDATn associé au paquet de mise à jour courant DPACKn, puis lit (en utilisant éventuellement des données du bloc de données d'introduction PREDATn lu) le paquet de mise à jour courant DPACKn dans la mémoire 26. [0135] Dans certains modes de réalisation, le paquet de mise à jour courant DPACKn est recopié (lors de cette étape E36) dans une zone de mémoire tampon (par exemple dédiée) de l'unité de traitement 4. Cette solution est intéressante en ce que les traitements ultérieurs (étapes E38 et E40) peuvent être effectués en utilisant les données mémorisées dans la zone de mémoire tampon, sans interaction entre l'unité de traitement 4 et le support mémoire 20 (un arrachage du support mémoire 20 du connecteur 12 n'empêchant donc pas la poursuite de la mise à jour en cours). L'utilisation d'une pluralité de paquets de mise à jour DPACK1, DPACK2, DPACK3 est particulièrement avantageuse dans cc cas puisque chaque paquet DPACK1 ; DPACK2 ; DPACK3 peut être conçu individuellement pour contenir dans la zone de mémoire tampon, alors que l'ensemble des données de mise à jour (c'est-à-dire l'ensemble des composants informatiques contenus dans ces différents paquets de mise à jour) occuperait un volume trop important pour pouvoir être recopié dans la zone de mémoire tampon. La copie du paquet de mise à jour courant DPACKn dans une zone de mémoire tampon de l'unité de traitement 4 est en outre intéressante car un attaquant ne peut pas venir y altérer les données après la vérification de leur intégrité (étape E38 décrite ci-dessous). [0136] En variante (par exemple lorsque le paquet de mise à jour DPACKn a une taille su- périeure à la zone de mémoire tampon dédiée), on peut toutefois prévoir que l'unité de traitement 4 lise les données du paquet de mise à jour DPACKn dans la mémoire 26 au fur et à mesure de leur traitement aux étapes E38 et E40 décrites à présent. [0137] L'unité de traitement 4 vérifie à l'étape E38 que le condensat de référence inclus dans les métadonnées INDEX et associé au paquet de mise à jour courant DPACKn correspond effectivement au paquet de mise à jour courant DPACKn lu dans la mémoire 26 (afin de vérifier que ces données n'ont pas été altérées). En pratique, l'unité de traitement 4 applique la fonction de hachage précitée au paquet de mise à jour courant DPACKn et compare le résultat ainsi obtenu au condensat de référence inclus dans les métadonnées INDEX et associée au paquet de mise à jour courant DPACKn. [0138] En cas d'absence de vérification à l'étape E38, le paquet de mise à jour courant DPACKn n'est pas utilisé pour effectuer une mise à jour à l'étape E40 comme décrit ci-dessous. [0139] Si la vérification de l'étape E38 est correctement effectuée, l'unité de traitement 4 procède à l'étape E40 à l'installation des composants informatiques associés au paquet de mise à jour courant DPACKn. Un exemple de mise en oeuvre de cette étape est 17 décrit ci-dessous en référence à la figure 8. [0140] L'unité de traitement 4 détermine alors à l'étape E42 un statut associé à la mise à jour au moyen du paquet de mise à jour courant DPACKn (et mémorise par exemple ce statut en mémoire vive). Par exemple, lorsque la mise à jour s'est déroulée correctement à l'étape E40, le statut ainsi déterminé est représentatif de bon fonctionnement ; à l'inverse, lorsque la mise à jour de l'étape E40 n'a pas pu être effectuée (par exemple en l'absence de vérification à l'étape E38) ou ne s'est pas déroulée correctement, le statut déterminé est représentatif d'une erreur. [0141] L'unité de traitement 4 détermine à l'étape E44 si tous les paquets de mise à jour DPACK1, DPACK2, DPACK3 ont été traités. [0142] Dans la négative, le procédé boucle à l'étape E36 pour traitement d'un autre paquet de mise à jour en tant que paquet de mise à jour courant DPACKn. [0143] Dans l'affirmative, le procédé se poursuit à l'étape E46 à laquelle l'unité de traitement 4 écrit dans la mémoire 26 les statuts successivement déterminés (lors des passages à l'étape E42) pour les mises à jour respectivement effectuées au moyen des différents paquets de mise à jour DPACK1, DPACK2, DRACK3. L'unité de traitement 4 peut éventuellement en outre produire une signature de l'ensemble de ces statuts (par application à l'ensemble des statuts d'un algorithme cryptographique de signature utilisant une clé privée mémorisée dans l'unité de traitement 4) et écrire cette signature (en association avec les statuts) dans la mémoire 26. [0144] L'unité de traitement 4 peut alors commander à l'étape E48 l'affichage sur une interface utilisateur (non représentée) du véhicule 2 d'un message signalant que le support mémoire 20 peut être retiré du connecteur 12. L'opérateur (ou le propriétaire du véhicule, le cas échéant) peut alors déconnecter le support mémoire 20 du connecteur 12. [0145] La figure 8 présente un exemple de procédé d'installation de composants infor- matiques dans le véhicule 2 au moyen d'un paquet de mise à jour DPACK (tel que le paquet de mise à jour courant DPACKn lors de l'étape E40 décrite ci-dessus). [0146] On se place ici dans le cas où l'unité de traitement 4 peut traiter le paquet de mise à jour DPACK (comme décrit ci-après) soit du fait que le paquet de mise à jour DPACK a été recopié dans une zone de mémoire tampon de l'unité de traitement 4, soit (directement) par lecture de données au sein du paquet de mise à jour DPACK mémorisé dans la mémoire 26 du support mémoire 20 (voir les explications relatives à l'étape E36 à ce sujet). [0147] L'unité de traitement 4 procède alors à l'étape E50 à la vérification du certificat constructeur R.cert (qui contient notamment la clé publique R.Kpub utilisée dans la suite pour vérifier des signatures). [0148] Comme indiqué plus haut, le certificat R.cert est ici contenu dans un champ au 18 format cms du paquet de mise à jour DRACK. [0149] Pour vérifier le certificat constructeur R.cert, on applique un algorithme crypto- graphique de vérification de signature utilisant la clé publique CA.Kpub à la signature R.sig et aux données signées (ici les métadonnées R.md et la clé publique R.Kpub). (On rappelle que la clé publique CA.Kpub fait partie du certificat CA.cert, contenu lui-aussi ici dans le champ au format CMS susmentionné.) En pratique, on compare par exemple un condensat des données signées et le résultat obtenu par application à la signature R.sig d'un algorithme cryptographique (ici de type RSA) utilisant la clé publique CA.Kpub. [0150] En l'absence de vérification (c'est-à-dire en cas d'inégalité à l'étape de comparaison du condensat précité et du résultat précité), il est mis fin au processus d'installation (le statut déterminé à l'étape E42 décrite ci-dessus étant dans ce cas un statut descriptif d'erreur). [0151] En cas de vérification positive à l'étape E50 (c'est-à-dire en cas d'égalité à l'étape de comparaison du condensat précité et du résultat précité), l'unité de traitement peut vérifier si le certificat R.cert n'a pas expiré en comparant la date et l'heure à l'instant concerné aux dates et heures d'expiration mentionnées dans les métadonnées R.md. [0152] Si le certificat est expiré, il est mis fin au processus d'installation (le statut déterminé à l'étape E42 décrite ci-dessus étant dans ce cas un statut descriptif d'erreur). [0153] Si le certificat est valide, l'unité de traitement 4 procède à l'étape E52 à la véri- fication du certificat d'autorité CA.cert (qui contient notamment la clé publique CA.Kpub utilisée comme décrit ci-dessus). [0154] Comme indiqué plus haut, le certificat CA.cert est ici contenu dans un champ au format cms du paquet de mise à jour DPACK. [0155] Pour vérifier le certificat d'autorité CA.cert, on applique un algorithme crypto- graphique de vérification de signature utilisant la clé publique ROOT.Kpub à la signature CA.sig et aux données signées (ici les métadonnées CA.md et la clé publique CA.Kpub). En pratique, on compare par exemple un condensat des données signées et le résultat obtenu par application à la signature CA.sig d'un algorithme cryptographique (ici de type RSA) utilisant la clé publique ROOT.Kpub. [0156] La clé publique ROOT.Kpub est par exemple mémorisée (lors de la fabrication de l'unité de traitement 4) au sein d'une mémoire non-volatile de l'unité de traitement 4. [0157] En l'absence de vérification (c'est-à-dire en cas d'inégalité à l'étape de comparaison du condensat précité et du résultat précité), il est mis fin au processus d'installation (le statut déterminé à l'étape E42 décrite ci-dessus étant dans ce cas un statut descriptif d'erreur). [0158] En cas de vérification positive à l'étape E52 (c'est-à-dire en cas (l'égalité à l'étape de comparaison du condensat précité et du résultat précité), l'unité de traitement peut 19 vérifier si le certificat CA.cert n'a pas expiré en comparant la date et l'heure à l'instant concerné aux dates et heures d'expiration mentionnées dans les métadonnées CA.md. [0159] Si le certificat est expiré, il est mis fin au processus d'installation (le statut déterminé à l'étape E42 décrite ci-dessus étant dans ce cas un statut descriptif d'erreur). [0160] Si le certificat est valide, on peut vérifier de la même manière la validité du certificat racine ROOT.cert en comparant la date et l'heure à l'instant donné aux dates et heures d'expiration du certificat racine ROOT.cert mentionnées dans les tnétadonnées ROOT.md. [0161] Si le certificat est expiré, il est mis fin au processus d'installation (le statut déterminé à l'étape E42 décrite ci-dessus étant dans ce cas un statut descriptif d'erreur). [0162] Si le certificat est valide, l'unité de traitement 4 vérifie à l'étape E54 certaines parties du paquet de mise à jour DPACK. [0163] L'unité de traitement vérifie en particulier à l'étape E54 l'intégrité du manifeste DPACKIND (inclus dans le paquet de mise à jour DPACK). [0164] Pour ce faire, l'unité de traitement applique un algorithme cryptographique de véri- fication de signature utilisant la clé publique R.Kpub à la signature SIG(DPACKIND) et au manifeste DPACKIND. En pratique, on compare par exemple un condensat du manifeste DPACKIND et le résultat obtenu par application à la signature SIG(DPACKIND) d'un algorithme cryptographique (ici de type RSA) utilisant la clé publique R.Kpub. (On rappelle que la validité du certificat R.ccrt contenant la clé publique R.Kpub a été vérifiée à l'étape E50.) [0165] En l'absence de vérification (c'est-à-dire en cas d'inégalité à l'étape de comparaison du condensat précité et du résultat précité), il est mis fin au processus d'installation (le statut déterminé à l'étape E42 décrite ci-dessus étant dans ce cas un statut descriptif d'erreur). [0166] En cas de vérification positive à l'étape E54 (c'est-à-dire en cas d'égalité à l'étape de comparaison du condensat précité et du résultat précité), le processus d'installation peut se poursuivre par le traitement des différents paquets d'équipements ECUPACK1, ECUPACK2, ECUPACKn comme expliqué à présent. [0167] On décrit ci-dessous à titre d'exemple le traitement du paquet d'équipement ECUPACKn, étant entendu que les autres paquets d'équipement (soit au total plusieurs paquets d'équipement) subissent le même traitement. [0168] L'unité de traitement 4 débute ce traitement par la mise en oeuvre à l'étape E55 d'une vérification du contenu du paquet d'équipement ECUPACKn concerné, en comparant par exemple le condensat H(ECUPACKn) contenu dans le manifeste DPACKIND et un condensat obtenu par application de la fonction de hachage (ici SHA256) au paquet d'équipement ECUPACKn lu dans la mémoire 26. [0169] En l'absence de vérification (c'est-à-dire si le condensat H(ECUPACKn) du manifeste DPACKIND diffère du condensat obtenu sur la base du paquet d'équipement ECUPACKn le paquet d'équipement ECUPACKn n'est pas transmis à l'équipement électronique concerné (comme décrit ci-après) et le statut déterminé à l'étape E42 décrite ci-dessus peut signaler ce problème. [0170] En cas de vérification positive à l'étape E55 (c'est-à-dire en cas d'égalité entre le condcnsat H(ECUPACKn) du manifeste DPACKIND et le condensat obtenu sur la base du paquet d'équipement ECUPACKn lu), l'unité de traitement 4 transmet à l'étape E56 le paquet d'équipement ECUPACKn à l'équipement électronique concerné. [0171] Cet équipement électronique est l'un des équipements électroniques chargés de l'installation des composants informatiques, soit ici la première unité électronique de commande 6 et/ou la passerelle 8. [0172] Chaque paquet d'équipement ECUPACK contient les données du paquet de mise à jour DPACK destinées à un équipement électronique particulier (ici première unité électronique de commande 6 ou passerelle 8), c'est-à-dire les données du paquet d'équipement ECUPACKn destiné à cet équipement électronique (avec ou sans les composants informatiques COMPI, COMP2, COMPi eux même selon le mode de réalisation concerné). [0173] Dans les modes de réalisation où les composants informatiques COMP1, COMP2, COMPi sont mémorisés dans la mémoire 26 indépendamment d'un paquet d'équipement ECUPACK, les composants informatiques COMPI, COMP2, COMPi associés au paquet d'équipement ECUPACKn sont également transmis à cette occasion (étape E56) de l'unité de traitement 4 (qui lit ces composants informatiques dans la mémoire 26) à l'équipement électronique concerné (première unité électronique de commande 6 et/ou passerelle 8). [0174] Chaque équipement électronique concerné (parmi une pluralité d'équipements élec- troniques) reçoit ainsi un paquet d'équipement ECUPACK à l'étape E58 (et éventuellement en outre les composants informatiques COMPI, COMP2, COMPi associés, lorsque ceux-ci sont séparés du paquet d'équipement ECUPACK). On décrit dans la suite la mise en oeuvre du procédé pour un tel équipement électronique (ici première unité électronique de commande 6 ou passerelle 8), des étapes similaires étant toutefois en pratique mises en oeuvre pour les autres équipements électroniques recevant un paquet d'équipement ECUPACK. [0175] L'équipement électronique (soit ici la première unité électronique de commande 6 ou la passerelle 8) peut alors éventuellement mettre en oeuvre à l'étape E60 une étape de vérification du certificat constructeur R.cert et du certificat d'autorité CA.cert. On rappelle que dans l'exemple décrit ici, ces certificats R.cert et CA.cert font partie d'un champ de type cms du paquet d'équipement ECUPACK. 21 [0176] Les vérifications de l'étape E60 (effectuées par l'équipement électronique 6, 8 concerné) sont similaires à celle réalisées aux étapes E50 et E52 décrites plus haut par l'unité de traitement 4, et ne seront donc pas décrites en détail ici. [0177] En l'absence de vérification à l'étape E60, il est mis fin au processus d'installation au sein de l'équipement 6, 8 concerné. Un message d'erreur peut par ailleurs être envoyé à l'unité de traitement 4 (afin que l'unité de traitement 4 soit informée de cc problème lors de la détermination du statut à l'étape E42 décrite plus haut, par exemple). [0178] En cas de vérification positive à l'étape E60, l'équipement électronique 6, 8 concerné procède à l'étape E62 à la vérification de l'intégrité du manifeste ECUPACKIND (reçu au sein du paquet d'équipement ECUPACKIND). [0179] Pour ce faire, l'équipement électronique 6, 8 concerné applique un algorithme cryp- tographique de vérification de signature utilisant la clé publique R.Kpub à la signature SIG(ECUPACKIND) et au manifeste ECUPACKIND. En pratique, on compare par exemple un condensai du manifeste ECUPACKIND et le résultat obtenu par application à la signature SIG(ECUPACKIND) d'un algorithme cryptographique (ici de type RSA) utilisant la clé publique R.Kpub. (On rappelle que la validité du certificat R.cert contenant la clé publique R.Kpub a été vérifiée à l'étape E60.) [0180] En l'absence de vérification (c'est-à-dire en cas d'inégalité à l'étape de comparaison du condensai précité et du résultat précité), il est mis fin au processus d'installation au niveau de l'équipement électronique 6, 8 concerné, éventuellement avec envoi d'un message d'erreur à l'unité de traitement 4 (afin que l'unité de traitement 4 soit informée de ce problème lors de la détermination du statut à l'étape E42 décrite plus haut, par exemple). [0181] En cas de vérification positive à l'étape E62 (c'est-à-dire en cas d'égalité à l'étape de comparaison du condensat précité et du résultat précité), l'équipement électronique 6, 8 concerné vérifie à l'étape E64 si l'identifiant VIN du véhicule 2 inclus dans le manifeste ECUPACKIND correspond (c'est-à-dire en pratique est égal) à l'identifiant VIN du véhicule 2 mémorisé (par exemple dans une mémoire non-volatile) au sein de l'équipement électronique 6, 8. [0182] En l'absence de vérification (c'est-à-dire en cas (l'inégalité entre l'identifiant VIN indiqué dans le manifeste ECUPACKIND et l'identifiant mémorisé), il est mis fin au processus d'installation au niveau de l'équipement électronique 6, 8 concerné, éventuellement avec envoi d'un message d'erreur à l'unité de traitement 4 (afin que l'unité de traitement 4 soit informée de ce problème lors de la détermination du statut à l'étape E42 déciite plus haut, par exemple). [0183] En cas de vérification positive à l'étape E64 (c'est-à-dire en cas d'égalité entre l'identifiant VIN indiqué dans le manifeste ECUPACKIND et l'identifiant mémorisé), l'installation peut se poursuivre à l'étape E62 décrite à présent. [0184] On décrit dans la suite le traitement d'un seul composant informatique COMPi associé au paquet d'équipement ECUPACK (que ce composant informatique soit intégré au paquet d'équipement ECUPACK ou mémorisé séparément du paquet d'équipement ECUPACK). En pratique, plusieurs composants informatiques (tous étant associés au paquet d'équipement ECUPACK) peuvent être traités comme décrit pour le composant informatique COMPi. [0185] L'équipement électronique 6, 8 vérifie ce composant informatique COMPi. [0186] Tout d'abord, à l'étape E66, l'équipement électronique 6, 8 compare le condensat H(COMPi) contenu dans le manifeste ECUPACKIND et un condensat obtenu par application de la fonction de hachage (ici SHA256) au composant informatique COMPi reçu. (On rappelle que l'intégrité du manifeste ECUPACKIND a été vérifiée à l'étape E62.) [0187] En cas de vérification négative (c'est-à-dire si le condensat H(COMPi) contenu dans le manifeste ECUPACKIND diffère du condensat obtenu), il est mis fin à l'installation du composant informatique COMPi, éventuellement avec envoi d'un message d'erreur à l'unité de traitement 4 (afin que l'unité de traitement 4 soit informée de cc problème lors de la détermination du statut à l'étape E42 décrite plus haut, par exemple). [0188] En cas de vérification positive à l'étape E66 (c'est-à-dire en cas d'égalité entre le condensat H(COMPi) contenu dans le manifeste ECUPACKIND et le condensat obtenu), la vérification du composant informatique COMPi se poursuit à l'étape E68. [0189] L'équipement électronique 6, 8 vérifie alors à l'étape E68 l'intégrité du manifeste COMPIND du composant informatique COMPi. [0190] Pour ce faire, l'équipement électronique 6, 8 concerné applique un algorithme cryp- tographique de vérification de signature utilisant la clé publique BK.Kpub à la signature SIG(COMPIND) et au manifeste COMPIND. En pratique, on compai-e par exemple un condensat du manifeste COMPIND et le résultat obtenu par application à la signature SIG(COMPIND) d'un algorithme cryptographique (ici de type RSA) utilisant la clé publique BK.Kpub. [0191] La clé publique BK.Kpub est par exemple mémorisée dans une mémoire non-volatile de l'équipement électronique 6, 8 concerné. [0192] En l'absence de vérification (c'est-à-dire en cas d'inégalité à l'étape de comparaison du condensat précité et du résultat précité), il est mis fin au processus d'installation du composant informatique COMPi, éventuellement avec envoi d'un message d'erreur à l'unité de traitement 4 (afin que l'unité de traitement 4 soit informée de ce problème lors de la détermination du statut à l'étape E42 décrite plus haut, par exemple). [0193] En cas de vérification positive de la signature SIG(COMPIND) (c'est-à-dire en cas d'égalité à l'étape de comparaison du condensat précité et du résultat précité), l'équipement électronique 6, 8 compare le condensat H(CONTEN) contenu dans le 23 manifeste COMPIND et un condensat obtenu par application de la fonction de hachage (ici SHA256) au contenu CONTEN du composant informatique COMPi reçu. [0194] En l'absence de vérification (c'est-à-dire en cas d'inégalité entre le condensat H(CONTEN) du manifeste COMPIND et le condensat obtenu), il est mis fin au processus d'installation du composant informatique COMPi, éventuellement avec envoi d'un message d'erreur à l'unité de traitement 4 (afin que l'unité de traitement 4 soit informée de cc problème lors de la détermination du statut à l'étape E42 décrite plus haut, par exemple). [0195] En cas de vérification positive (c'est-à-dire en cas d'égalité entre le condensat H(CONTEN) du manifeste COMPIND et le condensat obtenu), le procédé d'installation se poursuit comme décrit à présent. [0196] Dans le cas par exemple où le véhicule 2 est un véhicule à moteur thermique, on peut alors prévoir une étape E70 d'attente de mise en fonctionnement du moteur thermique, cc qui permet en pratique de s'assurer que (grâce à la charge au moyen de l'alternateur) l'alimentation électrique est à un niveau nominal et/ou pourra répondre à une sollicitation en courant et/ou que tous les équipements électroniques sont en fonctionnement et/ou que le composant informatique COMPi pourra être correctement installé dans l'équipement électronique concerné). En variante, une alimentation électrique supplémentaire peut être utilisée (par exemple en parallèle de la batterie du véhicule), de sorte que l'étape E70 est optionnelle. [0197] Lorsque le moteur thermique est en fonctionnement (ou sans cette condition, notamment pour un véhicule sans moteur thermique), l'équipement électronique 6, 8 concerné commande à l'étape E72 l'installation du composant informatique COMPi, c'est-à-dire la mémorisation du composant informatique COMPi dans une mémoire non-volatile (réinscriptible) en vue de son utilisation ultérieure. [0198] Dans certains cas (par exemple pour la première unité électronique de commande 6), l'installation du composant informatique COMPi est effectuée au sein même de l'équipement électronique (ici la première unité électronique de commande 6) qui a mis en oeuvre les étapes préalables de vérification E60 à E68 décrites ci-dessus. [0199] Dans d'autres cas en revanche (ici pour la passerelle 8), l'équipement électronique (ici la passerelle 8) chargé de l'installation, et ayant dans ce cadre effectué les étapes préalables de vérification E60 à E68, commande l'installation du composant informatique COMPi au sein d'un autre équipement électronique, ici la seconde unité électronique de commande 10. La passerelle 8 commande ainsi par exemple la mémorisation du composant informatique COMPi dans une mémoire non-volatile (réinscriptible) de la seconde unité électronique de commande 10. [0200] On prévoit ici de ne pas utiliser les composants informatiques dès leur installation, mais lorsque d'autres conditions sont remplies comme décrit à présent. 24 [0201] Lorsque le véhicule 2 est un véhicule à moteur thermique, on peut utiliser une étape E74 d'attente de l'arrêt du fonctionnement du moteur thermique. [0202] Lorsque le moteur thermique du véhicule 2 est à l'arrêt (ou que le véhicule 2 n'utilise aucun moteur thermique), l'unité de traitement 4 affiche sur une interface utilisateur (par exemple un écran disposé dans l'habitacle du véhicule 2) une indication que des composants informatiques ont été installés et sont prêts à être utilisés (étape E76). [0203] L'unité de traitement 4 attend alors à l'étape E78 une réponse de l'utilisateur (par exemple le conducteur du véhicule 2), par exemple via l'interface utilisateur précitée (éventuellement l'écran susmentionné lorsque cet écran est tactile). [0204] En cas de réponse négative de le(s) composant(s) informatique(s) installé(s) à l'étape E72 n'est (ne sont) pas utilisé(s). [0205] En cas de réponse positive de l'utilisateur à l'étape E78, l'unité de traitement 4 émet, à destination des différents équipements électroniques concernés (ici la première unité électronique de commande 6 et, via la passerelle 8, la seconde unité électronique de commande 10), une commande CMD d'activation des composants informatiques installés (étape E80). [0206] Les composants informatiques installés sont alors activés (étape E82). [0207] Pour les composants informatiques logiciels, des instructions comprises dans le composant informatique concerné peuvent alors être exécutées par le processeur de l'équipement électronique 6, 10 dans lequel le composant informatique a été installé. [0208] Pour les composants informatiques formés de données manipulables, des données comprises dans le composant informatique concerné peuvent être manipulées par le processeur de l'équipement électronique 6, 10 dans lequel le composant informatique a été installé. 25 REVENDICATIONS[Revendication 1] Support mémoire (20) comprenant des moyens de communication (22, 24) aptes à établir une communication avec une unité de traitement (4) d'un véhicule (2) et une mémoire (26) dans laquelle sont stockés : - au moins deux structures de données (DPACK1, DPACK2) lisibles chacune par ladite unité de traitement (4) lorsque ladite communication est établie ; - au moins deux composants informatiques (COMP I ; COMP) respectivement associés aux deux structures dc données (DPACK1, DPACK2) ; - des métadonnées (INDEX) comprenant, pour au moins une desdites structures de données (DPACK1, DPACK2), un condensat de référence associé à la structure de données concernée ; et - une signature (SIG(INDEX)) des métadonnées. [Revendication 2] Support mémoire selon la revendication 1, dans lequel au moins une desdites structures de données (DPACK1) contient deux paquets de données (ECUPACK1, ECUPACK2) respectivement destinés à deux équipements électroniques (6, 8) du véhicule (2). [Revendication 3] Support mémoire selon la revendication 1 ou 2, dans lequel au moins une desdites structures (DPACK1) comprend un paquet d'équipement (ECUPACK) associé à l'un desdits composants infornaatiques (COMP1). [Revendication 4] Support mémoire selon la revendication 3, dans lequel le paquet d'équipement (ECUPACK) comprend un identifiant (VIN) de véhicule. [Revendication 5] Procédé d'installation de composants informatiques au sein d'un véhicule (2), comprenant les étapes suivantes : - établissement (E30) d'une communication entre une unité de traitement (4) du véhicule et un support mémoire (20) conforme à l'une des revendications 1 à 4 en utilisant lesdits moyens de communication (22, 24) ; - transfert (E32) des métadonnées (INDEX) et de la signature (SIG(INDEX)) des métadonnées du support mémoire (20) à l'unité de traitement (4) via la communication établie ; - vérification (E34) de la signature (SIG(INDEX)) des métadonnées sur la base des métadonnées transférées ; - pour chaque structure de données (DPACK1 ; DPACK2), transfert (E36) de la structure de données concernée du support mémoire (20) à 26 [Revendication 6] [Revendication 7] [Revendication 8] [Revendication 9] [Revendication 10] l'unité de traitement (4) via la communication établie, détermination d'un condcnsat calculé sur la base de la structure de données reçue, et comparaison (E38) du condensat calculé et du condensat de référence associé à la structure de données concernée (DPACK1 ; DPACK2). Procédé selon la revendication 5, dans lequel la structure de données concernée comprend un paquet d'équipement (ECUPACK), le procédé comprenant en outre, en cas de comparaison positive, une étape de transmission (E56) du paquet d'équipement (ECUPACK) à destination d'un équipement électronique (6 ; 8) du véhicule (2). Procédé selon la revendication 6, dans lequel l'équipement électronique (6 ; 8) commande (E72) la mémorisation, dans une mémoire non-volatile, d'un composant informatique (COMPi) associé au paquet d'équipement (ECUPACK). Procédé selon la revendication 5 prise dans la dépendance de la revendication 2, comprenant, en cas de comparaison positive, des étapes de transmission de chacun des deux paquets de données (ECUPACK1, ECUPACK2) à l'équipement électronique (6 ; 8) auquel le paquet de données concerné est destiné. Procédé de préparation d'un support mémoire (20) conforme à l'une des revendications 1 à 4, comprenant les étapes suivantes : - stockage (E0) d'une pluralité de composants informatiques (COMP1, COMP2, COMPi, COMPx) dans une module de stockage (S) ; - réception (E12) d'un ensemble de données comprenant lesdites structures de données (DPACK1, DPACK2), lesdites métadonnées (INDEX) et ladite signature (SIG(INDEX)) ; - lecture (E14) des composants infoimatiques (COMP1 ; COMP) associés auxdites structures de données (DPACK1, DPACK2) dans le module de stockage (S) ; - écriture (E18), dans la mémoire (26) du support mémoire (20), des données dudit ensemble et desdits composants informatiques lus. Procédé selon la revendication 9, comprenant une étape de réception (EO) cl' au moins un composant informatique de ladite pluralité indépendamment de l'étape de réception (E12) de l'ensemble de données.