FR 3096160 A1 20201120 FR 1905119 A 20190516 Description Titre de l'invention : Procédé d'installation d'un composant informatique et équipement électronique associé Domaine technique de l'invention [0001] 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. [0002] Elle trouve une application particulièrement avantageuse dans le cadre du télé- chargement d'un tel composant informatique au sein d'un véhicule, mais s'applique également lorsque le composant informatique est chargé localement dans le véhicule, par exemple à partir d'une carte mémoire. [0003] Elle concerne plus particulièrement un procédé d'installation d'un composant in- formatique et un équipement électronique associé. Etat de la technique [0004] On cherche dans certaines situations à installer un composant informatique 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] Une telle installation de composant informatique a naturellement des conséquences sur le fonctionnement ultérieur du véhicule et doit être réalisée de manière contrôlée. Présentation de l'invention [0006] Dans ce contexte, la présente invention propose un procédé d'installation d'un composant informatique dans un équipement électronique équipant un véhicule. comprenant des étapes consistant à : - recevoir un paquet d'équipement comprenant un premier manifeste incluant un condensat du composant informatique ; - vérifier l'intégrité du premier manifeste ; - recevoir le composant informatique ; - vérifier la correspondance entre le condensat du composant informatique et le composant informatique reçu ; - installer le composant informatique seulement en cas de vérification positive de l'intégrité du premier manifeste et de vérification positive de la correspondance. [0007] Ainsi, grâce à l'invention, le véhicule reçoit une structure de données associée au composant informatique et participant (à l'aide notamment du condensat) à la vérification de l'intégrité du composant informatique. La solution proposée rend en outre possible la transmission séparée du paquet d'équipement et du composant informatique lui-même, ce qui donne plus de souplesse lors de la conception du véhicule et de ses 2 équipements électroniques. [0008] On peut prévoir par ailleurs que le premier manifeste susmentionné inclue un premier identifiant de véhicule et que le procédé d'installation comprenne alors des étapes consistant à : - comparer le premier identifiant de véhicule à un second identifiant de véhicule mémorisé au sein du véhicule ; - installer le composant informatique seulement en cas de comparaison positive du premier identifiant et du second identifiant. [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] - le paquet d'équipement comprend une première signature ; [0011] - l'intégrité du manifeste est vérifiée en appliquant un algorithme cryptographique de vérification de signature à la première signature et au premier manifeste ; [0012] - le composant informatique est reçu indépendamment du paquet d'équipement ; [0013] - le composant informatique est reçu au sein du paquet d'équipement ; [0014] - le composant informatique comprend une seconde signature et un contenu ; [0015] - le procédé comprend une étape de vérification de l'intégrité du contenu au moyen de la seconde signature. [0016] Le procédé peut comprendre par ailleurs des étapes consistant à : - recevoir un conteneur comprenant ledit paquet d'équipement et un deuxième manifeste ; - vérification de l'intégrité du deuxième manifeste. [0017] Ce deuxième manifeste peut alors comprendre un premier identifiant de véhicule et le procédé d'installation peut dans ce cas comprendre des étapes consistant à : - comparer le premier identifiant de véhicule à un second identifiant de véhicule mémorisé au sein du véhicule - transmettre le paquet d'équipement seulement en cas de comparaison positive du premier identifiant et du second identifiant. [0018] Le conteneur peut alors par exemple comprendre un autre paquet d'équipement destiné à un autre équipement électronique. [0019] Ce conteneur peut par ailleurs être reçu en provenance d'un serveur distant (par exemple directement via une communication établie entre le serveur distant et le véhicule, cette communication pouvant utiliser en partie une liaison radio entre le véhicule et un réseau cellulaire de téléphonie) en réponse à une requête émise par le véhicule ; en variante, le conteneur peut être reçu d'une carte mémoire insérée dans un lecteur équipant le véhicule. [0020] L'invention concerne enfin un équipement électronique destiné à équiper un véhicule 3 et comprenant : - un module de réception d'un paquet d'équipement comprenant un manifeste incluant un condensai d'un composant informatique ; - un module de vérification de l'intégrité du manifeste ; - un module de réception du composant informatique ; - un module de vérification de la correspondance entre le condensai du composant informatique et. le composant informatique reçu ; - un module d'installation conçu pour installer le composant informatique seulement en cas de vérification positive de l'intégrité du manifeste et de vérification positive de la correspondance. [0021] On peut prévoir par ailleurs que le manifeste inclue un premier identifiant de véhicule et l'équipement électronique peut alors comprendre un module de comparaison du premier identifiant de véhicule et d'un second identifiant du véhicule mémorisé au sein du véhicule. [0022] Le module d'installation peut être conçu pour installer le composant informatique seulement en cas de vérification positive de r intégrité du manifeste, de comparaison positive du premier identifiant et du second identifiant, et de vérification positive de la correspondance. [0023] Un tel équipement électronique est par exemple une unité électronique de commande (ou calculateur) comprenant un processeur et une mémoire mémorisant des instructions de programme d'ordinateur exécutables par le processeur. [0024] Les modules précités sont par exemple mis en oeuvre ici par la coopération du processeur et de certaines instructions conçues pour mettre en oeuvre la fonctionnalité attribuée au module concerné (comme décrit plus loin) lorsque ces instructions sont exécutées par le processeur. [0025] 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 [0026] 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. [0027] Sur les dessins annexés : [0028] [fig.1] représente schématiquement un système dans lequel peut être mise en oeuvre l'invention ; [0029] [fig.2] représente un exemple d'organisation de données utilisable dans le cadre de l'invention ; [0030] [fig.3] représente un autre exemple d'organisation de données utilisable dans le cadre de l'invention ; et [0031] [fig.4] présente un exemple de procédé d'installation dc composants informatiques au sein d'un véhicule conforme à l'invention. [0032] Le système de la figure 1 comprend un véhicule V (par exemple un véhicule au- tomobile), un réseau de téléphonie mobile N, un réseau étendu I (tel que le réseau Internet) et un serveur distant S. [0033] Le véhicule V comprend une unité de communication 2, une unité dc traitement 4, une première unité électronique de commande 6, une passerelle 8 et une seconde unité électronique de commande 10. [0034] On a représenté sur la figure 1 les éléments du véhicule V utiles à la compréhension de l'invention, mais le véhicule V comprend bien entendu en pratique d'autres éléments, notamment d'autres unités électroniques de commande ou calculateurs. [0035] Les équipements électroniques mentionnés ci-dessus (unité de communication 2, 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 cc 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). [0036] 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. [0037] Comme représenté schématiquement en figure 1, l'unité de traitement 4 est reliée à l'unité de communication 2, à 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 communication 2, 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 Nenvork"). [0038] La passerelle 8 est par ailleurs reliée à la seconde unité électronique de commande 10, par exemple au moyen d'un bus dédié. [0039] Le véhicule V peut comprendre en outre un lecteur 12 d'une carte mémoire 20, utilisable dans une variante de réalisation de l'invention, comme mentionné plus loin. [0040] L'unité de communication 2 est conçue pour mettre en oeuvre une communication C (comme représenté schématiquement en figure 1 par une ligne en trait plein qui signifie que cette connexion est de type physique, par exemple 30/40, WiFi ou autre) dans le réseau de téléphonie mobile N et peut ainsi établir une connexion avec le serveur distant S via le réseau de téléphonie mobile N (en utilisant notamment une liaison radio entre le véhicule V et un réseau cellulaire de téléphonie faisant partie du réseau de téléphonie mobile N) et le réseau étendu L de sorte que l'unité de traitement 4 et le serveur distant S peuvent échanger des données D (comme représenté schématiquement en figure 1 par une ligne pointillée qui signifie que cette connexion est de type logique), notamment dans le cadre de l'installation de composants informatiques au sein du véhicule V, comme décrit ci-après. [0041] La figure 2 représente un exemple d'organisation de données, utilisable dans le cadre de l'invention. [0042] Ces données comprennent notamment des composants informatiques COMP1, COMP2, COMPi que l'on souhaite installer dans un ou plusieurs équipement(s) électronique(s) du véhicule V, ici notamment dans la première unité électronique de commande 6 et/ou dans la seconde unité électronique de commande 10, désignées l'une et l'autre par le vocable « équipement électronique ». [0043] Les composants informatiques COMP1, COMP2, COMPi sont ici encapsulés au sein d'une structure arborescente comme suit : - un paquet de téléchargement DPACK comprend un ou plusieurs paquet(s) d'équipement ECUPACKI, ECUPACK2, ECUPACKn relatif(s) (chacun) à un équipement électronique du véhicule V ; - 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. [0044] Chacun de ces paquets contient une signature numérique ("digital signature" en anglais) utilisée en vue de l'installation des composants informatiques, comme décrit dans la suite. La vérification des signatures numériques, telle qu'envisagée plus bas, nécessite une infrastructure cryptographique particulière, décrite à présent. [0045] Pour alléger la présentation, on désigne simplement par "signature" dans la suite toute signature numérique. [0046] Sont utilisés en particulier dans la suite : - 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.cert 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. [0047] Une clé privée CA.Kpriv est associée à la clé publique CA.Kpub. [0048] De même, une clé privée R.Kpriv est associée à la clé publique R.Kpub. [0049] Par clé publique et clé privée associées, on entend ici une clé publique et une clé 6 privée associées dans une infrastructure à clé publique (ou PKI pour "Publie Key Infrastructure"). [0050] 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 ; 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 le clé publique associée à la clé privée précitée. [0051] 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.Kpuh (cette opération étant réalisée par exemple par une autorité de certification). [0052] La signature R.sig du certificat constructeur R.cert 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). [0053] On décrit à présent en détail les différentes structures de données représentée à la figure 2. [0054] 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 COMPIND. [0055] 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é. [0056] Le condensat H(CONTEN) est obtenu par application d'une fonction de hachage (par exemple de type SHA-256) au contenu CONTEN. [0057] La signature SIG(COMPIND) est obtenue par application au manifeste COMIND d'un algorithme cryptographique de signature utilisant la clé privée BK.Kpriv. [0058] Ces opérations sont par exemple effectuées par un organisme de certification du contenu CONTEN (par exemple du logiciel) concerné. [0059] Chaque paquet d'équipement ECUPACK comprend ici : - un ou plusieurs composant(s) informatique(s) COMP1, COMP2, COMPi tel que 7 décrit ci-dessus ; - un manifeste ECUPACKIND comprenant un condensat H(COMPI), 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. [0060] Plusieurs variantes de mise à disposition de l'identifiant VIN peuvent être mises en oeuvre. 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. [0061] En variante toutefois, on peut cependant autoriser cette manipulation, par exemple en plaçant l'identifiant VIN de véhicule au sein du manifeste DPACKIND décrit plus bas, comme c'est le cas dans la variante représentée en figure 3. 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 (lu véhicule V tel que mémorisé (ici au sein de l'unité de traitement 4). [0062] Selon d'autres modes de réalisation envisageables, l'identifiant VIN peut être placé à la fois dans le manifeste DPACKIND et dans le manifeste ECUPACKIND, ou dans aucun de ces deux manifestes, 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. [0063] Ici, l'identifiant VIN de véhicule V est un nombre associé de manière unique à un véhicule, couramment désigné sous l'appellation VINT (pour "Vehicle Identification Number"). [0064] 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). [0065] La signature SIG(ECUPACKIND) est obtenue par application au manifeste 8 ECUPACKTND d'un algorithme cryptographique de signature utilisant la clé privée R.Kpriv (associée au certificat constructeur R.cert). [0066] 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). [0067] 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 cc cas, ce champ peut comprendre la signature SIG(ECUPACKIND), le certificat d'autorité CA.cert et le certificat constructeur R.cert. [0068] Le paquet de téléchargement DPACK comprend : - un ou plusieurs paquet(s) d'équipement ECUPACKI, 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 ECUPACKI, ECUPACK2, ECUPACKn contenus dans le paquet de téléchargement DPACK, ainsi qu'éventuellement un descriptif des paquets d'équipement ECUPACKI, ECUPACK2, ECUPACKn contenus dans le paquet de téléchargement DPACK (avec par exemple une indication, pour chaque paquet d'équipement ECUPACKI, ECUPACK2, ECUPACKn, de l'équipement électronique destinataire du paquet d'équipement concerné) ; - une signature SIG(DPACKIND) du manifeste DPACKIND. [0069] 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 téléchargement DPACK (après définition des équipements électroniques visés et des besoins respectifs de chacun de ces équipements). [0070] 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). [0071] 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ées et les composants informatiques à installer dans ces équipements électroniques. [0072] En pratique, la signature SIG(DPACKIND) est par exemple contenue dans un champ dédié du paquet de téléchargement DPACK, par exemple un champ au format cms 9 (pour "Cryprographic Message Symax"). Dans ce cas, ce champ peut comprendre la signature SIG(DPACKIND), le certificat d'autorité CA.cert et le certificat constructeur R.cert. [0073] 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 V visé par l'installation (et peut par exemple être utilisé pour une flotte de véhicules). Les paquets d'équipement ECUPACKI, ECUPACK2, ECUPACKn (et par conséquent le paquet de téléchargement DPACK) sont en revanche spécifiquement conçus pour le véhicule V. [0074] La figure 3 présente une variante envisageable pour l'organisation des données au sein du paquet de téléchargement DPACK. [0075] Comme déjà indiqué, dans cette variante, l'identifiant VIN de véhicule est placé au sein du manifeste DPACKIND. [0076] Par ailleurs, les composants informatiques COMP1, COMP2, COMPi relatifs à un équipement électronique donné ne sont pas compris dans le paquet d'équipement ECUPACKI destiné à cet équipement électronique, mais extérieurs à celui-ci, afin de pouvoir éventuellement être transmis séparément du paquet d'équipement ECUPACKI, comme expliqué plus bas. [0077] Le paquet d'équipement ECUPACKI comprend dans ce cas : - un manifeste ECUPACKIND comprenant un condensat H(COMP1), H(COMP2), H(COMPi) pour chacun des composants informatiques COMP1, COMP2, COMPi associés à l'équipement électronique concerné ; - une signature SIG(ECUPACKIND) du manifeste ECUPACKIND. [0078] On décrit à présent en référence à la figure 4 un exemple de procédé d'installation de composants informatiques au sein du véhicule V conforme à l'invention. [0079] Ce procédé débute à l'étape E2 au cours de laquelle l'unité de traitement 4 émet une requête REQ à destination du serveur distant S. Par cette requête, le véhicule V cherche à déterminer si des composants informatiques sont disponibles pour installation au sein du véhicule V, par exemple pour mise à jour de certains composants logiciels ou de certaines données (telles que des données cartographiques). [0080] La requête REQ est par exemple émise périodiquement par l'unité de traitement 4. En pratique, des coordonnées électroniques du serveur distant S sont par exemple mémorisées au sein de l'unité de traitement 4 et utilisées pour transmettre la requête REQ à destination du serveur distant S. Les coordonnées électroniques font de préférence référence à une connexion sécurisée telle que SSL (acronyme bien connu de l'expression anglaise Secure Sockets Layer). [0081] La requête REQ peut inclure l'identifiant VIN du véhicule V. [0082] Le serveur distant S reçoit la requête REQ à l'étape E4 et détermine (par exemple sur la base de l'identifiant VIN inclus dans la requête REQ) si des composants infor- matiques sont disponibles pour téléchargement pour le véhicule V. [0083] On suppose ici que des composants informatiques sont disponibles pour télé- chargement et installation dans le véhicule V. Le serveur S transmet par conséquent à l'étape E6 un conteneur global GLOB à l'unité de traitement 4. [0084] Ce conteneur global GLOB comprend le manifeste DPACKIND, la signature associée SIG(DPACKIND) et les paquets d'équipement ECUPACKI, ECUPACK2, ECUPACKn. Par conséquent, selon les modes de réalisation, ce conteneur global GLOB comprend ou ne comprend pas les composants informatiques COMPI, COMP2, COMPi. [0085] En effet, selon une première possibilité de réalisation, on peut également transmettre à cette étape E6 tout ou partie des composants informatiques COMPI, COMP2, COMPi (ces composants transmis à l'étape E6 n'étant alors pas transmis à l'étape E26 décrite plus bas). Ces composants informatiques peuvent alors être transmis soit au sein des paquets d'équipements ECUPACK (par exemple dans le cadre de la structure de données représentée en figure 2), soit à côté du paquet d'équipements ECUPACK1 concerné (par exemple dans le cadre de la structure de données représentée en figure 3). [0086] Selon une seconde possibilité de réalisation, le conteneur global GLOB transmis à l'étape E6 ne contient aucun des composants informatiques COMPI, COMP2, COMPi (ces composants informatiques étant alors transmis lors d'une ou plusieurs étapes conforme(s) à l'étape E26 décrite plus bas). [0087] L'unité de traitement 4 reçoit le conteneur global GLOB à l'étape E8 et peut ainsi mémoriser celui-ci. Le conteneur global GLOB est ici reçu directement via la communication établie entre le serveur distant S et le véhicule V, cette communication utilisant en partie dans le cas présent une liaison radio entre le véhicule V et le réseau cellulaire de téléphonie déjà mentionné. [0088] En variante, le conteneur global GLOB (avec ou sans composants informatiques) pourrait être reçu à l'étape E8 en provenance d'une carte mémoire 20 insérée dans le lecteur 12 (et connectée par ce biais à l'unité de traitement 4) comme indiqué plus haut. Les étapes E2 à E6 ne sont dans ce cas pas mises en oeuvre. [0089] On remarque que, dans les modes de réalisation où le conteneur global GLOB transmis ne contient pas les composants informatiques COMPI, COMP2, COMPi (ou certains au moins d'entre eux), la taille mémoire requise au sein de l'unité de traitement 4 pour mémoriser le conteneur global GLOB reçu peut être réduite. Autrement dit, il n'est pas nécessaire de prévoir au sein de l'unité de traitement 4 une mémoire tampon adaptée à mémoriser l'ensemble du paquet de téléchargement DPACK. [0090] L'unité de traitement 4 procède alors à l'étape EIO à la vérification du certificat 11 constructeur R.cert (qui contient notamment la clé publique R.Kpuh utilisée dans la suite pour vérifier des signatures). [0091] Comme indiqué plus haut, le certificat R.cert est ici contenu dans un champ au format cms du paquet de téléchargement DPACK (et donc du conteneur global GLOB reçu à l'étape ES). [0092] Pour vérifier le certificat constructeur R.cert, on applique un algorithme crypto- graphique de vérification de signature utilisant la clé publique CA.Kpuh à la signature R.sig et aux données signées (ici les métadonnécs R.md et la clé publique R.Kpuh). (On rappelle que la clé publique CA.Kpuh 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. [0093] 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, éventuellement avec envoi d'un message d'erreur à destination du serveur distant S. [0094] En cas de vérification positive à l'étape E10 (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. [0095] Si le certificat est expiré, il est mis fin au processus d'installation, éventuellement avec envoi d'un message d'erreur à destination du serveur distant S. [0096] Si le certificat est valide, l'unité de traitement 4 procède à l'étape E12 à 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). [0097] Comme indiqué plus haut, le certificat CA.cert est ici contenu dans un champ au format cms du paquet de téléchargement DPACK (et donc du conteneur global GLOB reçu à l'étape E8). [0098] 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. [0099] 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. [0100] 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, 12 éventuellement avec envoi d'un message d'erreur à destination du serveur distant S. [0101] En cas de vérification positive à l'étape E12 (c'est-à-dire en cas d'égalité à l'étape de comparaison du condcnsat précité et du résultat précité), l'unité de traitement peut 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. [0102] Si le certificat est expiré, il est mis fin au processus d'installation, éventuellement avec envoi d'un message d'erreur à destination du serveur distant S. [0103] 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 métadonnées ROOT.md. [0104] Si le certificat est expiré, il est mis fin au processus d'installation, éventuellement avec envoi d'un message d'erreur à destination du serveur distant S. [0105] Si le certificat est valide, l'unité de traitement 4 vérifie à l'étape E14 certaines parties du conteneur global GLOB reçu à l'étape E8. [0106] L'unité de traitement vérifie en particulier à l'étape E14 l'intégrité du manifeste DPACKIND (reçu dans le conteneur global GLOB). [0107] 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.cert contenant la clé publique R.Kpub a été vérifiée à l'étape E10.) [0108] 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, éventuellement avec envoi d'un message d'erreur à destination du serveur distant S. [0109] En cas de vérification positive à l'étape E14 (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 se poursuit à l'étape E16 décrite à présent. [0110] L'unité de traitement 4 distribue à l'étape E16 divers paquets d'équipement ECUPACK aux équipements électroniques chargés de l'installation des composants informatiques, ici par exemple la première unité électronique de commande 6 et/ou la passerelle 8. [0111] Chaque paquet d'équipement ECUPACK contient les données du conteneur global GLOB 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 13 composants informatiques COMP1, COMP2, COMPi eux même selon le mode de réalisation concerné. [0112] Comme déjà indiqué, on peut en effet prévoir que tout ou partie des composants élec- troniques soit transmis dans le conteneur global GLOB à l'étape E6 et donc que certains paquets d'équipement ECUPACK au moins comprennent un ou plusieurs composant(s) informatique(s). [0113] Chaque équipcmcnt élcctroniquc concerné reçoit ainsi un paquet d'équipement ECUPACK à l'étape El 8. On décrit dans la suite la mise en oeuvre du procédé pour un tel équipcmcnt é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. [0114] 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 E20 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.ccrt font partie d'un champ de type cms du paquet d'équipement ECUPACK. [0115] Les vérifications de l'étape E20 (effectuées par l'équipement élcctroniquc 6, 8 concerné) sont similaires à celle réalisées aux étapes El0 et EU décrites plus haut par l'unité de traitement 4, et ne seront donc pas décrites en détail ici. [0116] En l'absence de vérification à l'étape E20, 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 (pour transmission éventuelle au serveur distant S, par exemple). [0117] En cas de vérification positive à l'étape E20, l'équipement électronique 6, 8 concerné procède à l'étape E22 à la vérification de l'intégrité du manifeste ECUPACKIND (reçu au sein du paquet d'équipement ECUPACKIND). [0118] 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 condensat 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 E20.) [0119] 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 au niveau de l'équipement électronique 6, 8 concerné, éventuellement avec envoi d'un message d'erreur à l'unité de traitement 4 (pour transmission éventuelle au serveur distant S, par exemple). 14 [0120] En cas de vérification positive à l'étape E22 (c'est-à-dire en cas d'égalité à l'étape de comparaison du condcnsat précité et du résultat précité), l'équipement électronique 6, 8 concerné vérifie à l'étape E24 si l'identifiant VIN du véhicule V inclus dans le manifeste ECUPACKIND correspond (c'est-à-dire en pratique est égal) à l'identifiant VIN du véhicule V mémorisé (par exemple dans une mémoire non-volatile) au sein de l'équipement électronique 6, 8. [0121] En l'absence de vérification (c'est-à-dire en cas d'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 (pour transmission éventuelle au serveur distant S, par exemple). [0122] En cas de vérification positive à l'étape E24 (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 E32 décrite plus loin (après réception des composants informatiques comme décrit à présent). [0123] En parallèle du traitement qui vient d'être mentionné au sein de l'équipement élec- tronique 6, 8 chargé de l'installation, le serveur distant S émet à l'étape E26 au moins un composant informatique COMPi du paquet de téléchargement DPACK, à destination de l'unité de traitement 4. (Bien que cela ne soit pas représenté en figure 4, cette émission du composant informatique COMPi peut être déclenchée suite à la réception par le serveur distant S d'une indication en provenance de l'unité de traitement 4, cette indication signalant par exemple une place suffisante dans la mémoire tampon pour mémorisation du composant informatique COMPi.) [0124] L'unité de traitement 4 reçoit le composant informatique COMPi à l'étape E28. [0125] On décrit dans la suite le traitement d'un seul composant informatique COMPi. En pratique, plusieurs composants informatiques sont reçus, au même instant ou à un instant ultérieur en fonction des capacités de la mémoire tampon de l'unité de traitement 4, et sont traités comme décrit pour le composant informatique COMPi. [0126] Lorsque le composant COMPi reçu à l'étape E28 permet de compléter (en utilisant des données du conteneur global GLOB) un paquet d'équipement ECUPACKn, l'unité de traitement 4 peut éventuellement mettre en oeuvre à l'étape E29 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 tel que reçu. [0127] 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 reçu), le composant informatique COMPi n'est pas communiqué à l'équipement électronique 6, 8 concerné et un message d'erreur peut éventuellement être envoyé au serveur distant S. [0128] En cas de vérification positive à l'étape E29 (c'est-à-dire en cas d'égalité entre le condensat H(ECUPACKn) du manifeste DPACKIND et le condensat obtenu sur la hase du paquet d'équipement ECUPACKn reçu), le composant informatique COMPi est distribué à l'équipement électronique 6, 8 concerné à l'étape E30. [0129] L'équipement électronique 6, 8 concerné reçoit ainsi le composant informatique COMPi à l'étape E32. [0130] L'équipement électronique 6, 8 peut alors vérifier ce composant informatique COMPi. [0131] Tout d'abord, à l'étape E34, 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 E22.) [0132] 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. [0133] En cas de vérification positive à l'étape E34 (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 E36. [0134] L'équipement électronique 6, 8 vérifie tout d'abord à l'étape E36 l'intégrité du manifeste COMPIND du composant informatique COMPi. [0135] 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. [0136] La clé publique BK.Kpub est par exemple mémorisée dans une mémoire non-volatile de l'équipement électronique 6, 8 concerné. [0137] 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 (pour transmission éventuelle au serveur distant S, par exemple). [0138] 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é), 16 l'équipement électronique 6, 8 compare le condensat H(CONTEN) contenu dans le manifeste COMPIND et un condcnsat obtenu par application de la fonction de hachage (ici SHA256) au contenu CONTEN du composant informatique COMPi reçu. [0139] 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 (pour transmission éventuelle au serveur distant S, par exemple). [0140] En cas de vérification positive (c'est-à-dire en cas d'égalité entre le condcnsat H(CONTEN) du manifeste COMPIND et le condensat obtenu), le procédé d'installation se poursuit comme décrit à présent. [0141] Dans le cas par exemple où le véhicule V est un véhicule à moteur thermique, on peut alors prévoir une étape E38 d'attente de mise en fonctionnement du moteur thermique (cc qui permet en pratique de s'assurer que tous les équipements électroniques sont en fonctionnement et que le composant informatique COMPi pourra être correctement installé dans l'équipement électronique concerné). [0142] Lorsque le moteur thermique est en fonctionnement (ou sans cette condition pour un véhicule sans moteur thermique), l'équipement électronique 6, 8 concerné commande 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. [0143] 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 E20 à E36 décrites ci-dessus. [0144] 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 E20 à E36, 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. [0145] 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. [0146] Lorsque le véhicule V est un véhicule à moteur thermique, on peut utiliser une étape E42 d'attente de l'arrêt du fonctionnement du moteur thermique. [0147] Lorsque le moteur thermique du véhicule V est à l'arrêt (ou que le véhicule V n'utilise aucun moteur thermique), l'unité de traitement 4 affiche sur une interface uti- 17 lisatcur (par exemple un écran disposé dans l'habitacle du véhicule V) une indication que des composants informatiques ont été installés et sont prêts à être utilisés (étape E44). [0148] L'unité de traitement 4 attend alors à l'étape E46 une réponse de l'utilisateur (par exemple le conducteur du véhicule V), par exemple via l'interface utilisateur précitée (éventuellement l'écran susmentionné lorsque cet écran est tactile). [0149] En cas de réponse négative de le(s) composant(s) informatique(s) installé(s) à l'étape E40 n'est (ne sont) pas utilisé(s). [0150] En cas de réponse positive de l'utilisateur à l'étape E46, 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 E48). [0151] Les composants informatiques installés sont alors activés (étape E50). [0152] 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é. [0153] 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é. 18 REVENDICATIONS[Revendication 1] Procédé d'installation d'un composant informatique (COMPI) dans un équipement électronique (6 ; 10) équipant un véhicule (V), comprenant des étapes consistant à : - recevoir (El 8) un paquet d'équipement (ECUPACK) comprenant un premier manifeste (ECUPACKIND) incluant un condensai (H(COMP1)) du composant informatique ; - vérifier (E22) l'intégrité du premier manifeste (ECUPACKIND) ; - recevoir (E32) le composant informatique (COMPI) ; - vérifier (E34) la correspondance entre le condensat (H(COMP1)) du composant informatique et le composant informatique (COMP1) reçu ; - installer (E40) le composant informatique (COMP1) seulement en cas de vérification positive de l'intégrité du premier manifeste (ECUPACKIND), et de vérification positive de la correspondance. [Revendication 2] Procédé selon la revendication 1, dans lequel le premier manifeste (ECUPACKIND) inclut un premier identifiant (VIN) de véhicule, et comprenant des étapes consistant à : - comparer (E24) le premier identifiant (VIN) de véhicule à un second identifiant de véhicule mémorisé au sein du véhicule (V) ; - installer (E40) le composant informatique (COMP1) seulement en cas de comparaison positive du premier identifiant (VIN) et du second identifiant. [Revendication 3] Procédé selon la revendication 1 ou 2, dans lequel le paquet d'équipement (ECUPACK) comprend une première signature (SIG(ECUPACKIND)) et dans lequel l'intégrité du manifeste (ECUPACKIND) est vérifiée en appliquant un algorithme cryptographique de vérification de signature à la première signature (SIG(ECUPACKIND)) et au premier manifeste (ECUPACKIND). [Revendication 4] Procédé selon l'une des revendications 1 à 3, dans lequel le composant informatique (COMP1) est reçu indépendamment du paquet d'équipement (ECUPACK). [Revendication 5] Procédé selon la revendication 1 à 3, dans lequel le composant in- formatique (COMP1) est reçu au sein du paquet d'équipement (ECUPACK). [Revendication 6] Procédé selon l'une des revendications 1 à 5, comprenant des étapes consistant à : - recevoir (E8) un conteneur (GLOB) comprenant ledit paquet 19 d'équipement (ECUPACK) et un deuxième manifeste (DPACKIND) ; - vérifier (E14) l'intégrité du deuxième manifeste (DPACKIND). [Revendication 7] Procédé selon la revendication 6, dans lequel le conteneur (GLOB) comprend un autre paquet d'équipement (ECUPACK2) destiné à un autre équipement électronique. [Revendication 8] Procédé selon l'une des revendications 6 ou 7, dans lequel le deuxième manifeste (DPACKIND) inclut un premier identifiant (VIN) de véhicule, et comprenant des étapes consistant à : - comparer (El 2) le premier identifiant (VIN) de véhicule à un second identifiant de véhicule mémorisé au sein du véhicule (V) ; - transmettre (El 6) ledit paquet d'équipement (ECUPACK) seulement en cas de comparaison positive du premier identifiant (VIN) et du second identifiant. [Revendication 9] Procédé selon l'une des revendications 6 à 8, dans lequel le conteneur (GLOB) est reçu en provenance d'un serveur distant (S) en réponse à une requête (REQ) émise par le véhicule (V). [Revendication 10] Procédé selon l'une des revendications 6 à 8, dans lequel le conteneur (GLOB) est reçu d'une carte mémoire (20) insérée dans un lecteur (12) équipant le véhicule (V). [Revendication 11] Procédé selon l'une des revendications 1 à 10, dans lequel le composant informatique (COMP1) comprend une seconde signature (SIG(COMPIND)) et un contenu (CONTEN), et dans lequel le procédé comprend une étape (E36) de vérification de l'intégrité du contenu (CONTEN) au moyen de la seconde signature (SIG(COMPIND)). [Revendication 12] Equipement électronique (6 ; 8) destiné à équiper un véhicule et comprenant: : - un module de réception d'un paquet d'équipement (ECUPACK) comprenant un manifeste (ECUPACKIND) incluant un condensat (H(COMPI)) d'un composant informatique ; - un module de vérification de l'intégrité du manifeste (ECUPACKIND) ; - un module de réception du composant informatique (COMPi) ; - un module de vérification de la correspondance entre le condensat (H(COMPI)) du composant informatique et le composant informatique (COMPi) reçu ; - un module d'installation conçu pour installer le composant informatique (COMPi) seulement en cas de vérification positive de l'intégrité du manifeste (ECUPACKIND) et de vérification positive de 20 [Revendication 13] la correspondance. Equipcment électronique (6 ; 8) selon la revendication 12, dans lequel le manifeste (ECUPACKIND) inclut un premier identifiant (VIN) de véhicule et comprenant: : - un module de comparaison du premier identifiant (VIN) de véhicule et d'un second identifiant du véhicule (V) mémorisé au sein du véhicule (V), dans lequel le module d'installation est conçu pour installer le composant informatique (COMPi) seulement en cas de vérification positive de l'intégrité du manifeste (ECUPACKIND), de comparaison positive du premier identifiant (VIN) et du second identifiant, et de vérification positive de la correspondance.