FR3096160A1 - Procédé d’installation d’un composant informatique et équipement électronique associé - Google Patents

Procédé d’installation d’un composant informatique et équipement électronique associé Download PDF

Info

Publication number
FR3096160A1
FR3096160A1 FR1905119A FR1905119A FR3096160A1 FR 3096160 A1 FR3096160 A1 FR 3096160A1 FR 1905119 A FR1905119 A FR 1905119A FR 1905119 A FR1905119 A FR 1905119A FR 3096160 A1 FR3096160 A1 FR 3096160A1
Authority
FR
France
Prior art keywords
computer component
vehicle
manifest
ecupackind
identifier
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR1905119A
Other languages
English (en)
Other versions
FR3096160B1 (fr
Inventor
Eric Abadie
Sebastien BESSIERE
Pascal MENIER
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Renault SAS
Nissan Motor Co Ltd
Original Assignee
Renault SAS
Nissan Motor Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to FR1905119A priority Critical patent/FR3096160B1/fr
Application filed by Renault SAS, Nissan Motor Co Ltd filed Critical Renault SAS
Priority to KR1020217041238A priority patent/KR20220007740A/ko
Priority to JP2021568090A priority patent/JP2022533105A/ja
Priority to US17/610,888 priority patent/US20220303139A1/en
Priority to PCT/EP2020/060506 priority patent/WO2020229074A1/fr
Priority to EP20717217.2A priority patent/EP3970315A1/fr
Priority to CN202080035832.0A priority patent/CN113841358A/zh
Publication of FR3096160A1 publication Critical patent/FR3096160A1/fr
Application granted granted Critical
Publication of FR3096160B1 publication Critical patent/FR3096160B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84—Vehicles

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)
  • Stored Programmes (AREA)
  • Storage Device Security (AREA)

Abstract

Un procédé d’installation d’un composant informatique (COMP1) dans un équipement électronique équipant un véhicule comprend des étapes consistant à : - recevoir un paquet d’équipement (ECUPACKIND) comprenant un manifeste (ECUPACKIND) incluant un condensat (H(COMP1)) du composant informatique ; - vérifier l’intégrité du manifeste (ECUPACKIND) ; - recevoir le composant informatique (COMP1) ; - vérifier la correspondance entre le condensat (H(COMP1)) du composant informatique et le composant informatique (COMPi) reçu ; - installer le composant informatique (COMP1) seulement en cas de vérification positive de l’intégrité du manifeste (ECUPACKIND) et de vérification positive de la correspondance. Un équipement électronique associé est également décrit. Figure pour l’abrégé : Fig. 2

Description

Procédé d’installation d’un composant informatique et équipement électronique associé
Domaine technique de l'invention
La présente invention concerne de manière générale l’installation des composants informatiques au sein des véhicules, en particulier des véhicules automobiles.
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.
Elle concerne plus particulièrement un procédé d’installation d’un composant informatique et un équipement électronique associé.
Etat de la technique
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.
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
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.
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 équipements électroniques.
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.
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 :
- le paquet d’équipement comprend une première signature ;
- 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 ;
- le composant informatique est reçu indépendamment du paquet d’équipement ;
- le composant informatique est reçu au sein du paquet d’équipement ;
- le composant informatique comprend une seconde signature et un contenu ;
- le procédé comprend une étape de vérification de l’intégrité du contenu au moyen de la seconde signature.
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.
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.
Le conteneur peut alors par exemple comprendre un autre paquet d’équipement destiné à un autre équipement électronique.
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.
L’invention concerne enfin un équipement électronique destiné à équiper un véhicule et comprenant :
- un module de réception d’un paquet d’équipement comprenant un manifeste incluant un condensat 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 condensat 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.
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.
Le module d’installation peut être conçu pour installer le composant informatique seulement en cas de vérification positive de l’intégrité du manifeste, de comparaison positive du premier identifiant et du second identifiant, et de vérification positive de la correspondance.
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.
Les modules précités sont par exemple mis en œuvre ici par la coopération du processeur et de certaines instructions conçues pour mettre en œuvre la fonctionnalité attribuée au module concerné (comme décrit plus loin) lorsque ces instructions sont exécutées par le processeur.
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
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.
Sur les dessins annexés :
représente schématiquement un système dans lequel peut être mise en œuvre l’invention ;
représente un exemple d’organisation de données utilisable dans le cadre de l’invention ;
représente un autre exemple d’organisation de données utilisable dans le cadre de l’invention ; et
présente un exemple de procédé d’installation de composants informatiques au sein d’un véhicule conforme à l’invention.
Le système de la figure 1 comprend un véhicule V (par exemple un véhicule automobile), 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.
Le véhicule V comprend une unité de communication 2, une unité de traitement 4, une première unité électronique de commande 6, une passerelle 8 et une seconde unité électronique de commande 10.
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.
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 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).
L’unité de traitement 4 peut elle-même être mise en œuvre en pratique au moyen d’une unité électronique de commande, ayant éventuellement d’autres fonctionnalités que celles décrites ci-dessous.
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 Network").
La passerelle 8 est par ailleurs reliée à la seconde unité électronique de commande 10, par exemple au moyen d’un bus dédié.
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.
L’unité de communication 2 est conçue pour mettre en œuvre 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 3G/4G, 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 I, 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.
La figure 2 représente un exemple d’organisation de données, utilisable dans le cadre de l’invention.
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 ».
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 ECUPACK1, 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.
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.
Pour alléger la présentation, on désigne simplement par "signature" dans la suite toute signature numérique.
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.
Une clé privée CA.Kpriv est associée à la clé publique CA.Kpub.
De même, une clé privée R.Kpriv est associée à la clé publique R.Kpub.
Par clé publique et clé privée associées, on entend ici une clé publique et une clé privée associées dans une infrastructure à clé publique (ou PKI pour "Public Key Infrastructure").
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.
La signature CA.sig du certificat d’autorité CA.cert est obtenue en appliquant un algorithme 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).
La signature R.sig du certificat constructeur R.cert est quant à elle obtenue en appliquant 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).
On décrit à présent en détail les différentes structures de données représentée à la figure 2.
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.
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é.
Le condensat H(CONTEN) est obtenu par application d’une fonction de hachage (par exemple de type SHA-256) au contenu CONTEN.
La signature SIG(COMPIND) est obtenue par application au manifeste COMIND d’un algorithme cryptographique de signature utilisant la clé privée BK.Kpriv.
Ces opérations sont par exemple effectuées par un organisme de certification du contenu CONTEN (par exemple du logiciel) concerné.
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.
Plusieurs variantes de mise à disposition de l’identifiant VIN peuvent être mises en œuvre. 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.
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 du véhicule V tel que mémorisé (ici au sein de l’unité de traitement 4).
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.
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 VIN (pour "Vehicle Identification Number").
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).
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).
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).
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 "Cryptographic 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.
Le paquet de téléchargement 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 téléchargement DPACK, ainsi qu’éventuellement un descriptif des paquets d’équipement ECUPACK1, ECUPACK2, ECUPACKn contenus dans le paquet de téléchargement DPACK (avec par exemple une indication, pour chaque paquet d’équipement ECUPACK1, ECUPACK2, ECUPACKn, de l’équipement électronique destinataire du paquet d’équipement concerné) ;
- une signature SIG(DPACKIND) du manifeste DPACKIND.
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).
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).
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.
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 (pour "Cryprographic Message Syntax"). Dans ce cas, ce champ peut comprendre la signature SIG(DPACKIND), le certificat d’autorité CA.cert et le certificat constructeur R.cert.
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 ECUPACK1, 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.
La figure 3 présente une variante envisageable pour l’organisation des données au sein du paquet de téléchargement DPACK.
Comme déjà indiqué, dans cette variante, l’identifiant VIN de véhicule est placé au sein du manifeste DPACKIND.
Par ailleurs, les composants informatiques COMP1, COMP2, COMPi relatifs à un équipement électronique donné ne sont pas compris dans le paquet d’équipement ECUPACK1 destiné à cet équipement électronique, mais extérieurs à celui-ci, afin de pouvoir éventuellement être transmis séparément du paquet d’équipement ECUPACK1, comme expliqué plus bas.
Le paquet d’équipement ECUPACK1 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.
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.
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).
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).
La requête REQ peut inclure l’identifiant VIN du véhicule V.
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 informatiques sont disponibles pour téléchargement pour le véhicule V.
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.
Ce conteneur global GLOB comprend le manifeste DPACKIND, la signature associée SIG(DPACKIND) et les paquets d’équipement ECUPACK1, ECUPACK2, ECUPACKn. Par conséquent, selon les modes de réalisation, ce conteneur global GLOB comprend ou ne comprend pas les composants informatiques COMP1, COMP2, COMPi.
En effet, selon une première possibilité de réalisation, on peut également transmettre à cette étape E6 tout ou partie des composants informatiques COMP1, 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).
Selon une seconde possibilité de réalisation, le conteneur global GLOB transmis à l’étape E6 ne contient aucun des composants informatiques COMP1, COMP2, COMPi (ces composants informatiques étant alors transmis lors d’une ou plusieurs étapes conforme(s) à l’étape E26 décrite plus bas).
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é.
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 œuvre.
On remarque que, dans les modes de réalisation où le conteneur global GLOB transmis ne contient pas les composants informatiques COMP1, 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.
L’unité de traitement 4 procède alors à l’étape E10 à 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).
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 E8).
Pour vérifier le certificat constructeur R.cert, on applique un algorithme cryptographique 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.
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.
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.
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.
Si le certificat est valide, l’unité de traitement 4 procède à l’étape E12 à la vérification du certificat d’autorité CA.cert (qui contient notamment la clé publique CA.Kpub utilisée comme décrit ci-dessus).
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).
Pour vérifier le certificat d’autorité CA.cert, on applique un algorithme cryptographique 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.
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.
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.
En cas de vérification positive à l’étape E12 (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 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.
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.
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.
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.
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.
L’unité de traitement vérifie en particulier à l’étape E14 l’intégrité du manifeste DPACKIND (reçu dans le conteneur global GLOB).
Pour ce faire, l’unité de traitement applique un algorithme cryptographique de vérification 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.)
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.
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.
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.
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 composants informatiques COMP1, COMP2, COMPi eux même selon le mode de réalisation concerné.
Comme déjà indiqué, on peut en effet prévoir que tout ou partie des composants électroniques 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).
Chaque équipement électronique concerné reçoit ainsi un paquet d’équipement ECUPACK à l’étape E18. On décrit dans la suite la mise en œuvre 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 œuvre pour les autres équipements électroniques recevant un paquet d’équipement ECUPACK.
L’équipement électronique (soit ici la première unité électronique de commande 6 ou la passerelle 8) peut alors éventuellement mettre en œuvre à 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.cert font partie d’un champ de type cms du paquet d’équipement ECUPACK.
Les vérifications de l’étape E20 (effectuées par l’équipement électronique 6, 8 concerné) sont similaires à celle réalisées aux étapes E10 et E12 décrites plus haut par l’unité de traitement 4, et ne seront donc pas décrites en détail ici.
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).
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).
Pour ce faire, l’équipement électronique 6, 8 concerné applique un algorithme cryptographique 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.)
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).
En cas de vérification positive à l’étape E22 (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 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.
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).
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).
En parallèle du traitement qui vient d’être mentionné au sein de l’équipement électronique 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.)
L’unité de traitement 4 reçoit le composant informatique COMPi à l’étape E28.
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.
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 œuvre à 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.
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.
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 base du paquet d’équipement ECUPACKn reçu), le composant informatique COMPi est distribué à l’équipement électronique 6, 8 concerné à l’étape E30.
L’équipement électronique 6, 8 concerné reçoit ainsi le composant informatique COMPi à l’étape E32.
L’équipement électronique 6, 8 peut alors vérifier ce composant informatique COMPi.
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.)
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.
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.
L’équipement électronique 6, 8 vérifie tout d’abord à l’étape E36 l’intégrité du manifeste COMPIND du composant informatique COMPi.
Pour ce faire, l’équipement électronique 6, 8 concerné applique un algorithme cryptographique de vérification de signature utilisant la clé publique BK.Kpub à la signature SIG(COMPIND) et au manifeste COMPIND. En pratique, on compare 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.
La clé publique BK.Kpub est par exemple mémorisée dans une mémoire non-volatile de l’équipement électronique 6, 8 concerné.
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).
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 manifeste COMPIND et un condensat obtenu par application de la fonction de hachage (ici SHA256) au contenu CONTEN du composant informatique COMPi reçu.
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).
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.
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 (ce 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é).
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.
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 œuvre les étapes préalables de vérification E20 à E36 décrites ci-dessus.
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.
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.
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.
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 utilisateur (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).
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).
En cas de réponse négative de l’utilisateur, le(s) composant(s) informatique(s) installé(s) à l’étape E40 n’est (ne sont) pas utilisé(s).
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).
Les composants informatiques installés sont alors activés (étape E50).
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é.
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é.

Claims (13)

  1. Procédé d’installation d’un composant informatique (COMP1) dans un équipement électronique (6 ; 10) équipant un véhicule (V), comprenant des étapes consistant à :
    - recevoir (E18) un paquet d’équipement (ECUPACK) comprenant un premier manifeste (ECUPACKIND) incluant un condensat (H(COMP1)) du composant informatique ;
    - vérifier (E22) l’intégrité du premier manifeste (ECUPACKIND) ;
    - recevoir (E32) le composant informatique (COMP1) ;
    - 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.
  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.
  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).
  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).
  5. Procédé selon la revendication 1 à 3, dans lequel le composant informatique (COMP1) est reçu au sein du paquet d’équipement (ECUPACK).
  6. Procédé selon l’une des revendications 1 à 5, comprenant des étapes consistant à :
    - recevoir (E8) un conteneur (GLOB) comprenant ledit paquet d’équipement (ECUPACK) et un deuxième manifeste (DPACKIND) ;
    - vérifier (E14) l’intégrité du deuxième manifeste (DPACKIND).
  7. Procédé selon la revendication 6, dans lequel le conteneur (GLOB) comprend un autre paquet d’équipement (ECUPACK2) destiné à un autre équipement électronique.
  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 (E12) le premier identifiant (VIN) de véhicule à un second identifiant de véhicule mémorisé au sein du véhicule (V) ;
    - transmettre (E16) ledit paquet d’équipement (ECUPACK) seulement en cas de comparaison positive du premier identifiant (VIN) et du second identifiant.
  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).
  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).
  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)).
  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 la correspondance.
  13. Equipement é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.
FR1905119A 2019-05-16 2019-05-16 Procédé d’installation d’un composant informatique et équipement électronique associé Active FR3096160B1 (fr)

Priority Applications (7)

Application Number Priority Date Filing Date Title
FR1905119A FR3096160B1 (fr) 2019-05-16 2019-05-16 Procédé d’installation d’un composant informatique et équipement électronique associé
JP2021568090A JP2022533105A (ja) 2019-05-16 2020-04-15 コンピューティングコンポーネントをインストールするための方法および関連付けられた電子デバイス
US17/610,888 US20220303139A1 (en) 2019-05-16 2020-04-15 Method for installing a computing component and associated electronic device
PCT/EP2020/060506 WO2020229074A1 (fr) 2019-05-16 2020-04-15 Procede d'installation d'un composant informatique et equipement electronique associe
KR1020217041238A KR20220007740A (ko) 2019-05-16 2020-04-15 컴퓨터 컴포넌트 및 연관된 전자 디바이스 설치 방법
EP20717217.2A EP3970315A1 (fr) 2019-05-16 2020-04-15 Procede d'installation d'un composant informatique et equipement electronique associe
CN202080035832.0A CN113841358A (zh) 2019-05-16 2020-04-15 用于安装数据处理组件的方法以及相关联的电子设备

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1905119 2019-05-16
FR1905119A FR3096160B1 (fr) 2019-05-16 2019-05-16 Procédé d’installation d’un composant informatique et équipement électronique associé

Publications (2)

Publication Number Publication Date
FR3096160A1 true FR3096160A1 (fr) 2020-11-20
FR3096160B1 FR3096160B1 (fr) 2021-09-10

Family

ID=67875656

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1905119A Active FR3096160B1 (fr) 2019-05-16 2019-05-16 Procédé d’installation d’un composant informatique et équipement électronique associé

Country Status (7)

Country Link
US (1) US20220303139A1 (fr)
EP (1) EP3970315A1 (fr)
JP (1) JP2022533105A (fr)
KR (1) KR20220007740A (fr)
CN (1) CN113841358A (fr)
FR (1) FR3096160B1 (fr)
WO (1) WO2020229074A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130111212A1 (en) * 2011-10-28 2013-05-02 GM Global Technology Operations LLC Methods to provide digital signature to secure flash programming function
US20170060559A1 (en) * 2015-08-25 2017-03-02 Ford Global Technologies, Llc Multiple-stage secure vehicle software updating

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9722781B2 (en) * 2014-07-09 2017-08-01 Livio, Inc. Vehicle software update verification
GB2541950B (en) * 2015-09-07 2020-01-08 Arm Ip Ltd Methods for verifying data integrity

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130111212A1 (en) * 2011-10-28 2013-05-02 GM Global Technology Operations LLC Methods to provide digital signature to secure flash programming function
US20170060559A1 (en) * 2015-08-25 2017-03-02 Ford Global Technologies, Llc Multiple-stage secure vehicle software updating

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
NILSSON D K ET AL: "Secure Firmware Updates over the Air in Intelligent Vehicles", COMMUNICATIONS WORKSHOPS, 2008. ICC WORKSHOPS '08. IEEE INTERNATIONAL CONFERENCE ON, IEEE, PISCATAWAY, NJ, USA, 19 May 2008 (2008-05-19), pages 380 - 384, XP031265266, ISBN: 978-1-4244-2052-0 *

Also Published As

Publication number Publication date
WO2020229074A1 (fr) 2020-11-19
FR3096160B1 (fr) 2021-09-10
US20220303139A1 (en) 2022-09-22
CN113841358A (zh) 2021-12-24
JP2022533105A (ja) 2022-07-21
EP3970315A1 (fr) 2022-03-23
KR20220007740A (ko) 2022-01-18

Similar Documents

Publication Publication Date Title
EP3759885B1 (fr) Protocole bus basé sur un courtier et architecture multi-client
CN111385191B (zh) 车载互联网关、车辆ota升级***和方法、计算机存储介质
US8972736B2 (en) Fully authenticated content transmission from a provider to a recipient device via an intermediary device
US20110225259A1 (en) System and method for communicating software applications to a motor vehicle
FR3030830A1 (fr) Procede de securisation de l'acces a au moins une fonctionnalite d'un vehicule automobile par un terminal mobile
US10474450B1 (en) System and method to transmit queued over-the-air software updates
EP3072309B1 (fr) Interface de communication virtuelle pour diagnostic de véhicule automobile
US20200007663A1 (en) Method and device for inter-process communication in network
FR3096160A1 (fr) Procédé d’installation d’un composant informatique et équipement électronique associé
WO2020126624A1 (fr) Architecture electronique pour systeme embarque
FR3096153A1 (fr) Procédé et dispositif de retour à un état précédent une mise à jour logicielle d’un calculateur d’un véhicule à distance
Dakroub et al. Analysis of software update in connected vehicles
WO2016180987A1 (fr) Procédé de commande d'une fonctionnalité d'un véhicule au moyen d'un terminal utilisateur
WO2021023694A1 (fr) Procédé d'écriture dans une zone de données sécurisée d'un calculateur sur bus embarqué de véhicule
EP3211855A1 (fr) Methode et systeme d'echange de donnees entre utilisateurs d'un vehicule
EP3987741A1 (fr) Support mémoire, procédé d'installation de composants informatiques au sein d'un vehicule et procédé de préparation d'un support mémoire
WO2017182597A1 (fr) Procédé de connexion d'un appareil électronique à un système embarqué de véhicule, appareil électronique et système embarqué de véhicule associés
JP6436123B2 (ja) 車両用情報通信システム、車両用情報通信方法、車載情報装置用プログラムおよびアプリケーションプログラム
FR3111447A1 (fr) Gestion de versions de logiciels embarqués à partir d’une empreinte informatique
FR3089651A1 (fr) Gestion conjointe par un calculateur embarque de véhicule automobile d’une fonction opérationnelle et d’une fonction passerelle entre des bus de communication de données
EP3259159B1 (fr) Procédé de mise en oeuvre d'une connexion entre un dispositif électronique esclave et un dispositif électronique maître, et dispositif électronique esclave associé
WO2022064118A1 (fr) Procédé et dispositif de mise à jour d'un logiciel d'un calculateur embarqué d'un véhicule, comportant une mémoire d'exécution, une mémoire de sauvegarde et une mémoire de contrôle
EP4281887A1 (fr) Procédé et dispositif de contrôle de l'accès de moyens informatiques externes de diagnostic à un bus de donnée embarqué d'un véhicule
FR3109001A1 (fr) Procédé sécurisé d’inhibition d’enregistrement des défauts d’équipements électroniques en vue d’une mise à jour d’un composant du véhicule par le client final
EP3992798A1 (fr) Elément sécurisé et procédé de communication entre un élément sécurisé et l'extérieur de l'élément sécurisé

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20201120

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

CA Change of address

Effective date: 20221005

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6