EP3987741A1 - 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 - Google Patents

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

Info

Publication number
EP3987741A1
EP3987741A1 EP20731502.9A EP20731502A EP3987741A1 EP 3987741 A1 EP3987741 A1 EP 3987741A1 EP 20731502 A EP20731502 A EP 20731502A EP 3987741 A1 EP3987741 A1 EP 3987741A1
Authority
EP
European Patent Office
Prior art keywords
data
vehicle
processing unit
memory medium
dpack1
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.)
Pending
Application number
EP20731502.9A
Other languages
German (de)
English (en)
Inventor
Eric Abadie
Sébastien BESSIERE
Devreese ARNAUD
Fradin BENOIT
Mayouma PACOME
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.)
Ampere 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
Application filed by Renault SAS, Nissan Motor Co Ltd filed Critical Renault SAS
Publication of EP3987741A1 publication Critical patent/EP3987741A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/024—Guidance services

Definitions

  • the present invention relates generally to the installation of computer components in vehicles, in particular motor vehicles.
  • the present invention provides a memory medium comprising communication means capable of establishing communication with a processing unit of a vehicle and a memory in which are stored:
  • metadata comprising, for at least one (and possibly for each) of said data structures, a reference digest associated with the data structure concerned;
  • the data structures (which correspond, for example, respectively to different vehicle update campaigns) can be successively processed by the vehicle processing unit.
  • This allows progressive updating of the vehicle, with a buffer memory area of smaller size (when such a buffer memory area is used to store each data structure) since only one data structure (corresponding to a single data structure). update campaign) will be processed at once.
  • the metadata comprising the digest and the signature of this metadata also make it possible to ensure that the data structures have not been altered.
  • At least one of said data structures contains two data packets respectively intended for two electronic equipment items of the vehicle;
  • At least one of said structures comprises an equipment package associated with one of said computer components
  • the equipment package includes a vehicle identifier.
  • the invention also proposes a method for installing computer components in a vehicle, comprising the following steps:
  • the data structure concerned can include an equipment package; the method can then further comprise, in the event of a positive comparison, a step of transmitting the equipment package to electronic equipment in the vehicle.
  • the electronic equipment can then control the storage, in a non-volatile memory, of a computer component associated with the equipment package.
  • the method may also include, in the event of a positive comparison, steps of transmitting each of the two data packets to the electronic equipment for which the data packet concerned is intended.
  • the invention proposes a process for preparing a memory medium as proposed above, comprising the following steps:
  • This method can include a step of receiving at least one computer component of said plurality independently of the step of receiving the set of data.
  • Figure 1 shows schematically a system in which the invention can be implemented
  • FIG. 2 represents a memory medium of the system of FIG. 1;
  • FIG. 3 shows an example of the organization of data within a memory of the memory medium of FIG. 2;
  • FIG. 4 shows an example of the architecture used for an update packet stored in this memory
  • FIG. 5 schematically represents an example of a possible method for the preparation of an update packet to be recorded in the memory medium of FIG. 2;
  • FIG. 6 schematically shows a method of preparing the memory medium of FIG. 2 with an organization of the data according to FIG. 3;
  • FIG. 7 shows schematically an example of a method of installing computer components in a vehicle of Figure 1; and [0029] FIG. 8 shows an example of a method of installing computer components by means of an update package.
  • the system of Figure 1 comprises a vehicle 2 (for example a motor vehicle) and a memory medium 20, such as a key connectable by universal serial bus (or USB key for "Universal Serial Bus"), or a memory card (for example an SD card, SD meaning "Secure Digitat '), or any other (removable) external memory device that can be connected locally to the vehicle 2.
  • a vehicle 2 for example a motor vehicle
  • a memory medium 20 such as a key connectable by universal serial bus (or USB key for "Universal Serial Bus"), or a memory card (for example an SD card, SD meaning "Secure Digitat '), or any other (removable) external memory device that can be connected locally to the vehicle 2.
  • a memory medium 20 such as a key connectable by universal serial bus (or USB key for "Universal Serial Bus"), or a memory card (for example an SD card, SD meaning "Secure Digitat '), or any other (removable) external memory device that can be connected locally to the vehicle 2.
  • the vehicle 2 comprises a processing unit 4, a first electronic control unit 6, a gateway 8 and a second electronic control unit 10.
  • FIG. 1 There is shown in Figure 1 the elements of the vehicle 2 useful for understanding the invention, but the vehicle 2 naturally includes other elements in practice, in particular other electronic control units or computers.
  • processing unit 4 first electronic control unit 6, gateway 8 and second unit control electronics 10
  • processing unit 4 can each be implemented in practice in the form of a microprocessor architecture; in this context in particular, each of these electronic items of equipment comprises a processor and at least one memory (for example a random access memory and / or a non-volatile memory).
  • the processing unit 4 can itself be implemented in practice by means of an electronic control unit, possibly having other functions than those described below.
  • the processing unit 4 is connected to the first electronic control unit 6 and to the gateway 8 in order to be able to exchange data with these various electronic equipment.
  • the processing unit 4, the electronic control unit 6 and the gateway 8 are for example connected to a (same) on-board computer network (not shown), for example a CAN bus (for "Controller Area Network) .
  • the gateway 8 is also connected to the second electronic control unit 10, for example by means of a dedicated bus.
  • the vehicle 2 further comprises a connector 12 connected to the processing unit 4 for connection to the memory medium 20, as explained below.
  • the memory medium 20 comprises a memory 26 (for example a rewritable non-volatile memory) and communication means 22, 24 capable of establishing communication with the processing unit 4.
  • a memory 26 for example a rewritable non-volatile memory
  • communication means 22, 24 capable of establishing communication with the processing unit 4.
  • these means of communication comprise a controller 24 and a connector 22 (for example a USB connector) which can be plugged into the connector 12 of the vehicle 2.
  • the memory medium 20 When the connector 22 of the memory medium 20 is plugged into the connector 12 connected to the processing unit 4, the memory medium 20 is supplied electrically and communication is established between the processing unit 4 and the controller 24 .
  • the processing unit 4 can request the reading of data stored in the memory 26: the controller 24 reads the requested data from the memory 26 and transmits the data read to the processing unit 4 via established communication.
  • the processing unit 4 can request the writing of data in the memory 26 (at a particular location): the data to be written (and the chosen location) are transmitted from the processing unit 4 to the controller 24 via the established communication and the controller 24 writes these transmitted data in the memory 26 (at the chosen location).
  • a public key infrastructure (or PKI for "Public Key Infrastructure") is set up.
  • a public key intended to be distributed
  • a private key kept secret by the signing entity
  • a data set can be signed by applying, to this data set, a cryptographic signature algorithm (here of RSA type) using the private key concerned; the signature can then be verified by means of an associated cryptographic signature verification algorithm (here also of the RSA type), using the public key associated with the aforementioned private key.
  • a cryptographic signature algorithm here of RSA type
  • an associated cryptographic signature verification algorithm here also of the RSA type
  • FIG. 3 shows an example of the organization of the data stored in the memory 26.
  • These data include a plurality of DPACK1, DPACK2, DPACK3 update packets.
  • each update packet DPACK1, DPACK2, DPACK3 is intended to be transmitted to the processing unit 4 of the vehicle 2 for the installation of at least one computer component at the within an electronic control unit (for example among the processing unit 4 itself, the first electronic control unit 6 and the second electronic control unit 10).
  • the computer component to be installed can be included in the update package DPACK1, DPACK2, DPACK3 aimed at installing this computer component (as is the case in the example described below in reference to figure 4).
  • the computer component COMP could however be stored in the memory 26 separately from the associated update packet, as schematically represented in dotted lines in FIG. 3.
  • the data stored in the memory 26 also includes:
  • TLS orchestration tools for example executable files or drivers
  • HMI interface data possibly usable by the processing unit 4 for display on a user interface (not shown) of the vehicle 2.
  • the orchestration performed by the TLS orchestration tool can for example include the sequencing and / or the scheduling of the operations to be implemented for the installation of the components, as well as possibly the management of the conditions of execution and / or errors appearing during execution and / or user exchanges (using the HMI interface data if necessary).
  • the INDEX metadata comprises for example a description (such as a list) of the update packets DPACK1, DPACK2, DPACK3 and, for each update packet DPACK1, DPACK2, DPACK3 stored in the memory 26, a reference condensate associated with the update packet DPACK1, DPACK2, DPACK3 concerned (this reference condensate being obtained on the basis of the update packet concerned, for example by applying a hash function).
  • the memory 26 can also store in practice the entry data blocks PREDAT1, PREDAT2, PREDAT3 associated respectively with the different update packets DPACK1, DPACK2, DPACK3.
  • An introduction data block PREDAT1, PREDAT2, PREDAT3 associated with a given update packet DPACK1, DPACK2, DPACK3 contains for example a storage address of this given update packet in the memory 26 and / or data interfaces usable by the processing unit 4 for display on a user interface (not shown) of the vehicle 2 specifically when the processing unit 4 processes the given update packet.
  • this architecture is based on a tree structure at several levels:
  • the DPACK update package includes one or more ECUPACK1, ECUPACK2, ECUPACKn equipment package (s) relating (each) to electronic equipment of the vehicle 2;
  • each ECUPACK equipment package includes data relating to one or more computer component (s) COMP1, COMP2, COMPi intended for a particular electronic equipment.
  • the computer components COMP1, COMP2, COMPi can themselves be included in the concerned ECUPACK equipment package (that is to say here encapsulated within the tree structure) as shown in figure 4, or, as a variant, be located (in practice: stored) outside the DPACK update package.
  • ROOT.cert root certificate containing ROOT.md metadata and a ROOT.Kpub public key associated with a ROOT.Kpriv private key;
  • CA.cert authority certificate containing CA.md metadata, a CA.Kpub public key and a CA.sig signature;
  • a private key CA.Kpriv is associated with the public key CA.Kpub.
  • a private key R.Kpriv is associated with the public key R.Kpub.
  • the CA.sig signature of the CA.cert authority certificate is obtained by applying a cryptographic signature algorithm using the private key ROOT.Kpriv to the set formed of the CA.md metadata and the public key CA.Kpub (this operation being performed for example by a certification authority).
  • the signature R.sig of the manufacturer certificate R.cert is for its part obtained by applying a cryptographic signature algorithm using the private key CA.Kpriv to the set formed of the metadata R.md and of the public key R. Kpub (this operation can also be carried out by the aforementioned certification).
  • Each COMP computer component to be installed comprises:
  • COMPIND manifesto containing in particular a digest H (CONTEN) of the content to be installed and possibly a description of the computer component, for example a description of the functions updated by this component;
  • These data to be installed can constitute software or part of software (for example a software update). This software or this part of software is then designed to be executed at least in part by a processor of the electronic equipment concerned. As a variant, these data to be installed can be data to be stored (for example map data) for subsequent manipulation by a processor of the electronic equipment concerned.
  • the H hash (CONTEN) is obtained by applying a hash function (for example of the SHA-256 type) to the CONTEN content.
  • a hash function for example of the SHA-256 type
  • the SIG (COMPIND) signature is obtained by applying to the COMIND manifesto a cryptographic signature algorithm using the private key BK.Kpriv.
  • Each package of ECUPACK equipment includes here:
  • an ECUPACKIND manifest comprising a hash H (COMP1), H (COMP2), H (COMPi) for each of the computer components COMP1, COMP2, COMPi contained in the ECUPACK equipment package, as well as possibly a vehicle identifier VIN and / or a description of the computer components COMP1, COMP2, COMPi contained in the package;
  • VIN identifier in the ECUPACK equipment package, as mentioned above, makes it possible to ensure that the computer component installed in the electronic equipment (for example a vehicle computer) is indeed the component assigned to this vehicle. Indeed, a component could very well be suitable for a multitude of vehicles of the same type, offering the possibility to a user, for example, of replacing a computer of his vehicle with a computer of another vehicle of the same type.
  • the inclusion of the VIN identifier in the ECUPACK equipment package makes it possible to prevent this manipulation.
  • the vehicle identifier VIN could be placed within the DPACKIND manifesto described below.
  • the equipment package ECUPACK to the electronic equipment concerned only in the event of a positive comparison between the identifier VIN received within the manifest DPACKIND and the identifier of the vehicle 2 as stored (here within the processing unit 4).
  • the VIN identifier can be placed both in the DPACKIND manifesto and in the ECUPACKIND manifesto.
  • the VIN identifier may not be placed in either of the two DPACKIND or ECUPACKIND manifests, in particular for a computer component compatible with any vehicle, such as for example a computer component comprising map data from a navigation system.
  • VIN vehicle Identification NumbeT
  • the condensates H (COMP1), H (COMP2), H (COMPi) are respectively obtained by applying a hash function (for example of SHA-256 type) to the data constituting the computer component COMP1, COMP2, COMPi concerned, for example when defining the ECUPACK equipment package (depending on the needs of the equipment concerned, in particular the updating needs of this equipment).
  • a hash function for example of SHA-256 type
  • the SIG (ECUPACKIND) signature is obtained by applying to the ECUPACKIND manifesto a cryptographic signature algorithm using the private key R.Kpriv (associated with the manufacturer certificate R.cert).
  • the SIG signature (ECUPACKIND) is for example contained in a dedicated field of the ECUPACK equipment package, for example a field in cms format (for "Syntax Message Cryptography").
  • this field can include the SIG signature (ECUPACKIND), the CA.cert authority certificate and the R.cert manufacturer certificate.
  • the DPACK update package includes:
  • a DPACKIND manifest including in particular a hash H (ECUPACK1), H (ECUPACK2), H (ECUPACKn) for each of the equipment packages ECUPACK1, ECUPACK2, ECUPACKn contained in the DPACK update package, as well as possibly a description equipment packages ECUPACK1, ECUPACK2, ECUPACKn contained in the DPACK update package (with for example an indication, for each equipment package ECUPACK1, ECUPACK2, ECUPACKn, of the electronic equipment recipient of the equipment package concerned );
  • the condensates H (ECUPACK1), H (ECUPACK2), H (ECUPACKn) are respectively obtained by applying a hash function (for example of SHA-256 type) to the equipment package ECUPACK2, ECUPACK2, ECUPACKn concerned , for example when defining the DPACK update package (after defining the targeted electronic devices and the respective needs of each of these devices).
  • a hash function for example of SHA-256 type
  • the SIG (DPACKIND) signature is obtained by applying to the DPACKIND manifesto a cryptographic signature algorithm using the private key R.Kpriv (associated with the manufacturer certificate R.cert).
  • the SIG signature (DPACKIND) is for example contained in a dedicated field of the DPACK update packet, for example a field at cms format (for "Cryprographic Message Syntax").
  • this field can include the SIG signature (DPACKIND), the CA.cert authority certificate and the R.cert manufacturer certificate.
  • each of the computer components COMP1, COMP2, COMPi is independent of the vehicle 2 targeted by the installation (and can for example be used for a fleet of vehicles) .
  • the equipment packages ECUPACK1, ECUPACK2, ECUPACKn can however be specifically designed for vehicle 2 (especially when the EUCPACKIND manifest contains the vehicle VIN identifier).
  • FIG. 5 schematically represents an example of a method that can be envisaged for the preparation of a DPACK update packet to be recorded within the memory medium 20.
  • first structure C typically an establishment of the automobile manufacturer
  • second structure G typically a dealer or a garage
  • the method of FIG. 5 comprises a step E0 during which computer components COMP1, COMP2, COMPi, COMPx are transmitted from the first structure C to the second structure G, where these computer components COMP1, COMP2, COMPi, COMPx are stored in a storage module S of the second structure G (for example a hard disk located in the premises of the second structure G).
  • This transmission is for example carried out via one or more computer network (s), for example via a wide area network such as the Internet, and can be encrypted.
  • the computer components COMP1, COMP2, COMPi, COMPx thus transmitted are various computer components capable of being used during updates of vehicles within the second structure G. As already indicated, these computer components COMP1, COMP2, COMPi, COMPx are not designed for a particular vehicle, but each of these computer components COMP1, COMP2, COMPi, COMPx can on the contrary be used for a fleet of vehicles.
  • the transmission of step EO can thus in practice be carried out in advance, that is to say before a possible visit of a vehicle within the second structure G (dealer or garage). This makes it possible to limit the volume of downloads to be carried out when the vehicle is present within the second structure G (see the transmission of step E10 described below).
  • the transmission of step EO can thus possibly be carried out at times when the available bandwidth is high, for example at night.
  • step EO is represented in the form of a single step
  • the different computer components COMP1, COMP2, COMPi, COMPx can be transmitted separately, at different times and moreover independently.
  • the method of FIG. 5 also comprises a step E2 of defining the updating needs of a particular vehicle, here the vehicle 2, that is to say a step of selecting computer components COMP1, COMP2 , COMPi to be installed in this vehicle 2.
  • the condensates H (COMP1), H (COMP2), H (COMPi) respectively associated with these computer components COMP1, COMP2, COMPi can thus be prepared (or read in memory).
  • the ECUPACKIND manifest of the concerned ECUPACK equipment package can therefore be constructed in step E4, in particular by combining the aforementioned condensates H (COMP1), H (COMP2), H (COMPi) and the identifier VIN of vehicle for vehicle 2 in which the computer components COMP1, COMP2, COMPi must be installed.
  • the method then comprises a step E6 during which the SIG signature (ECUPACKIND) is obtained by applying to the ECUPACKIND manifesto a cryptographic signature algorithm using the private key R.Kpriv (associated with the manufacturer certificate R.cert) .
  • the ECUPACK equipment package can thus be constructed by combining the ECUPACKIND manifesto and the SIG signature (ECUPACKIND), as well as possibly the computer components COMP1, COMP2, COMPi themselves (even if these computer components COMP1, COMP2 , COMPi will not ultimately be transmitted during step E10 as explained below).
  • the method of Figure 5 then comprises a step E8 of preparation the DPACK update package based in particular on the ECUPACK equipment package constructed in step E8, a DPACKIND manifest comprising a digest for each equipment package included in the DPACK update package, and d 'a SIG signature (DPACKIND), in accordance with what has been described above with reference to FIG. 4.
  • the method of FIG. 5 then comprises a step E10 of transmitting the DPACK update packet, without the computer components COMP1, COMP2, COMPn, from the first structure C to the second structure G.
  • This transmission is for example carried out via one or more computer network (s), for example via a wide area network such as the Internet, and can be encrypted.
  • the computer components are integrated into the DPACK update packet, the computer components are thus deleted from the DPACK update packet before transmission to the second structure G.
  • the DPACK update packet is therefore received within the second structure G in step E12, without the computer components COMP1, COMP2, COMPi.
  • a computer present in the second structure G consults for example, for each package of ECUPACK equipment, the description of the computer components COMP1, COMP2, COMPi referred to in this package of ECUPACK equipment (this description may be part of the ECUPACKIND manifesto as explained above) and reads on this basis the computer components COMP1, COMP2, COMPi in the storage module S.
  • data designating these components computer COMP1, COMP2, COMPi can be attached to the transmission performed during step E10.
  • a computer present in the second structure G can use these appended data in order to determine which computer components COMP1, COMP2, COMPi must be read in the storage module S.
  • the DPACK update package including the computer components COMP1, COMP2, COMPi can thus be reconstructed in step E16.
  • the DPACK update package and the computer components COMP1, COMP2, COMPi can thus be written into the memory 26 of the device. memory medium 20 in step E18.
  • an operator connects, for example, the memory medium 20 to the aforementioned computer (present in the second structure G) and initiates (by means of this computer) a write operation of the update packet DPACK (received at step E12 without computer component) and computer components (read in the storage module S in step E14) within the memory 26.
  • FIG. 6 schematically presents a process for preparing the memory medium 20 with an organization of the data as proposed in FIG. 3 described above.
  • Such a method can be implemented within the second structure G (dealer or garage) introduced in the context of FIG. 5, for example by means of a computer located in this second structure G and to which the support memory 20 is connected.
  • this method could be implemented on several sites depending on the step concerned, for example on a design site of the vehicle manufacturer for steps E20 to E26 and on a production site (or alternatively at a particular) for step E28.
  • each DPACK1 update package; DPACK2, DPACK3 corresponds for example to an update campaign for vehicle 2 and can thus contain computer components relating respectively to various electronic equipment items of the vehicle 2 (as is the case for the DPACK update package in FIG. 4).
  • a method such as that described above with reference to FIG. 5 can be used to obtain at least one DPACK1 update packet. ; DPACK2; DPACK3 and step E20 then corresponds to step E16 described above, where the update packet is reconstructed from data received at step E12 and from computer components read in a local storage module S at l 'step E14.
  • steps similar to steps E2 to E8 described above are used, for example, to obtain at least one update packet.
  • Step E20 can further include the preparation of the input data blocks PREDAT1, PREDAT2, PREDAT3 respectively associated with the update packets DPACK1, DPACK2, DPACK3 as described above.
  • the method of FIG. 6 then comprises a step E22 for preparing additional elements, such as for example the TLS orchestration tools and the HMI interface data.
  • the method of FIG. 6 then comprises a step E24 of preparing the INDEX metadata on the basis of the various update packets DPACK1, DPACK2, DPACK3 (as well as on the basis of the other elements contained in the memory 26 of which one wants to ensure integrity and authenticity, especially here the introduction data PREDAT1, PREDAT2, PREDAT3, the TLS orchestration tools and the HMI interface data).
  • step E24 comprises in particular, for each update packet DPACK1; DPACK2; DPACK3, calculating a hash (referred to as “reference hash” in the following) by applying a hash function (for example of SHA-256 type) to the update packet DPACK1; DPACK2; DPACK3 concerned.
  • step E24 further comprises the calculation of a digest for each of the other aforementioned elements, here the input data PREDAT1, PREDAT2, PREDAT3, the TLS orchestration tools and the HMI interface data. The condensates thus calculated are integrated into the INDEX metadata.
  • the method of FIG. 6 finally comprises a step E26 for producing the signature SIG (INDEX) by application to the INDEX metadata of a cryptographic signature algorithm using a private key Kpriv.
  • this private key can be the private key R. Kpriv already mentioned (and associated with the manufacturer certificate R.cert).
  • step E26 in particular is preferably carried out within the first structure C.
  • a dedicated private key can however be used as a variant (in particular when step E26 is carried out outside the first structure C, for example when this step E26 in particular is carried out within the second structure G as envisaged below).
  • the method of FIG. 6 can thus be completed by writing the data obtained and prepared during steps E20 to E26 (as has just been described) in the memory 26 of the memory medium 20, which makes it possible to obtain a memory 26 organized as shown in FIG. 3 and described above.
  • the memory 26 stores a plurality of update packets DPACK1, DPACK2, DPACK3 which may for example correspond in practice to several update campaigns for the vehicle 2.
  • this computer has for example implemented steps E22 to E26 and can control the writing of data in the memory 26 at step E28.
  • steps E20 to E26 when steps E20 to E26 are implemented within a site of the manufacturer, the data obtained and prepared during steps E20 to E26 can be downloaded to a personal computer located at a particular and written in the memory 26 of the memory medium 20 connected to this personal computer.
  • Figure 7 shows schematically an example of a method of installing computer components in the vehicle 2.
  • This method starts at step E30 by inserting the memory medium 20 into the connector 12 fitted to the vehicle 2 as described above with reference to FIG. 1.
  • This insertion step can be carried out in practice by a operator or vehicle owner 2.
  • communication is then established between the processing unit 4 and the controller 24 so that the processing unit 4 can in particular read data in the memory 26 of the memory medium 20.
  • the processing unit 4 can thus read in step E32 the INDEX metadata and the SIG signature (INDEX) stored in the memory 26 (as well as possibly the TLS orchestration tools and / or the data from HMI interface).
  • the INDEX metadata and the SIG signature (INDEX) are thus transferred (in practice recopied) from the memory medium 20 to the processing unit 4.
  • the processing unit 4 can then verify in step E34 that the signature SIG (INDEX) actually corresponds to the INDEX metadata, in practice by applying to the INDEX metadata and to the SIG signature (INDEX) a cryptographic verification algorithm.
  • the public key Kpub is for example stored in the processing unit 4 during the manufacture of the vehicle 2 (or alternatively after downloading into the processing unit 4 by means of a telematics module, not shown).
  • the method of FIG. 7 enters a loop for successive processing of the various update packets DPACK1, DPACK2, DPACK3, the update packet being processed. being designated DPACKn in the following.
  • the processing which follows can optionally be implemented using the TLS orchestration tools, for example by following a scheduling (or sequencing) of the blocks of introduction data PREDAT1, PREDAT2, PREDAT3 and / or DPACK1, DPACK2, DPACK3 update packets defined by the TLS orchestration tools and / or by implementing additional actions defined by the TLS orchestration tools and / or by execution (by the processing unit 4) of executable data contained in the TLS orchestration tools.
  • the processing unit 4 reads in step E36 (in the memory 26) the entry data block PREDATn associated with the current update packet DPACKn, then reads (possibly using data from the data introduction PREDATn read) the current update packet DPACKn in memory 26.
  • the current DPACKn update packet is copied (during this step E36) into a buffer memory area (for example dedicated) of the processing unit 4.
  • a buffer memory area for example dedicated
  • the subsequent processing steps E38 and E40
  • the subsequent processing can be performed using the data stored in the buffer memory area, without interaction between the processing unit 4 and the memory medium 20 (tearing of the memory medium 20 from the connector 12 therefore not preventing the continuation of the current update).
  • the use of a plurality of DPACK1, DPACK2, DPACK3 update packets is particularly advantageous in this case since each DPACK1 packet; DPACK2; DPACK3 can be individually designed to contain in the buffer memory area, while all of the update data (i.e.
  • the copy of the current update packet DPACKn in a buffer memory area of the processing unit 4 is also advantageous because an attacker cannot alter the data there after checking their integrity (step E38 described below). below).
  • the processing unit 4 checks in step E38 that the reference hash included in the INDEX metadata and associated with the current update packet DPACKn actually corresponds to the current update packet DPACKn read in the memory 26 (in order to verify that these data have not been altered). In practice, the processing unit 4 applies the aforementioned hash function to the current update packet DPACKn and compares the result thus obtained with the reference hash included in the INDEX metadata and associated with the current update packet DPACKn.
  • step E38 If there is no verification at step E38, the update packet current DPACKn is not used to perform an update at step E40 as described below.
  • step E38 If the verification of step E38 is correctly carried out, the processing unit 4 proceeds to step E40 to install the computer components associated with the current update package DPACKn.
  • step E40 An example of the implementation of this step is described below with reference to Figure 8.
  • the processing unit 4 determines in step E42 a status associated with the update by means of the current update packet DPACKn (and for example stores this status in random access memory). For example, when the update has taken place correctly in step E40, the status thus determined is representative of correct operation; conversely, when the update of step E40 could not be carried out (for example in the absence of verification in step E38) or did not take place correctly, the determined status is representative of an error.
  • the processing unit 4 determines in step E44 whether all the DPACK1, DPACK2, DPACK3 update packets have been processed.
  • step E36 for processing another update packet as the current update packet DPACKn.
  • step E46 the processing unit 4 writes in the memory 26 the successively determined statuses (during the passages to step E42) for the updates respectively. carried out by means of the various update packages DPACK1, DPACK2, DPACK3.
  • the processing unit 4 can optionally also produce a signature of all of these statuses (by applying to all the statuses of a cryptographic signature algorithm using a private key stored in the processing unit 4) and write this signature (in association with the statutes) in memory 26.
  • the processing unit 4 can then control in step E48 the display on a user interface (not shown) of the vehicle 2 of a message indicating that the memory medium 20 can be removed from the connector 12.
  • the operator or the owner of the vehicle, if applicable) can then disconnect the memory medium 20 from the connector 12.
  • FIG. 8 shows an example of a method of installing computer components in the vehicle 2 by means of a DPACK update package (such as the current update package DPACKn during step E40 described this- above).
  • processing unit 4 can process the DPACK update packet (as described below) or because the DPACK update packet has been copied into a zone buffer memory of the processing unit 4, or (directly) by reading data within the DPACK update packet stored in the memory 26 of the memory medium 20 (see the explanations relating to step E36 on this subject ).
  • step E50 the processing unit 4 then proceeds to step E50 to verify the manufacturer's certificate R.cert (which notably contains the public key R.Kpub used below to verify signatures).
  • the R.cert certificate is here contained in a field in cms format of the DPACK update package.
  • a cryptographic signature verification algorithm is applied using the public key CA.Kpub to the signature R.sig and to the signed data (here the metadata R.md and the public key R .Kpub).
  • the public key CA.Kpub is part of the CA.cert certificate, also contained here in the field in the above-mentioned CMS format.
  • step E42 In the absence of verification (that is to say in the event of an inequality at the step of comparing the aforementioned condensate and the aforementioned result), the installation process is terminated (the determined status in step E42 described above being in this case a descriptive error status).
  • the processing unit can verify whether the R.cert certificate has not expired by comparing the date and time at the relevant time to the expiration dates and times mentioned in the R.md metadata.
  • step E42 the installation process is terminated (the status determined in step E42 described above being in this case a descriptive error status).
  • step E52 the processing unit 4 proceeds to step E52 to verify the authority certificate CA.cert (which notably contains the public key CA.Kpub used as described above).
  • the CA.cert certificate is here contained in a field in cms format of the DPACK update package.
  • a cryptographic signature verification algorithm is applied using the public key ROOT.Kpub to the CA.sig signature and to the signed data (here the CA.md metadata and the key public CA.Kpub).
  • a digest of the signed data is compared with the result obtained by applying to the signature CA.sig a cryptographic algorithm (here of the RSA type) using the public key ROOT.Kpub.
  • ROOT.Kpub is for example stored (during the manufacture of the processing unit 4) in a non-volatile memory of the processing unit 4.
  • step E42 the installation process is terminated (the determined status in step E42 described above being in this case a descriptive error status).
  • the processing unit can verify whether the CA.cert certificate has not expired by comparing the date and time at the relevant time to the expiration dates and times mentioned in the CA.md metadata.
  • step E42 the installation process is terminated (the status determined in step E42 described above being in this case a descriptive error status).
  • the validity of the ROOT.cert root certificate can be checked in the same way by comparing the date and time at the given moment with the expiration dates and times of the ROOT.cert root certificate mentioned in the ROOT.md metadata.
  • step E42 If the certificate has expired, the installation process is terminated (the status determined in step E42 described above being in this case a descriptive error status).
  • step E54 the processing unit 4 checks in step E54 certain parts of the DPACK update packet.
  • the processing unit checks in particular at step E54 the integrity of the DPACKIND manifest (included in the DPACK update package).
  • the processing unit applies a cryptographic signature verification algorithm using the public key R.Kpub to the SIG (DPACKIND) signature and to the DPACKIND manifesto.
  • DPACKIND public key
  • a cryptographic algorithm here of RSA type
  • step E42 In the absence of verification (that is to say in the event of an inequality at the step of comparing the aforementioned condensate and the aforementioned result), the installation process is terminated (the determined status in step E42 described above being in this case a descriptive error status).
  • step E54 the installation process can continue with the processing of the various equipment packages ECUPACK1, ECUPACK2, ECUPACKn as explained now.
  • the processing unit 4 begins this processing by the implementation in step E55 of a verification of the content of the equipment package ECUPACKn concerned, for example by comparing the hash H (ECUPACKn) contained in the manifest DPACKIND and a hash obtained by applying the hash function (here SHA256) to the equipment packet ECUPACKn read in memory 26.
  • a verification of the content of the equipment package ECUPACKn concerned for example by comparing the hash H (ECUPACKn) contained in the manifest DPACKIND and a hash obtained by applying the hash function (here SHA256) to the equipment packet ECUPACKn read in memory 26.
  • step E55 In the event of a positive verification at step E55 (that is to say in the event of equality between the hash H (ECUPACKn) of the DPACKIND manifesto and the hash obtained on the basis of the equipment package ECUPACKn read ), the processing unit 4 transmits at step E56 the equipment package ECUPACKn to the equipment electronics concerned.
  • This electronic equipment is one of the electronic equipment responsible for installing computer components, here the first electronic control unit 6 and / or the gateway 8.
  • Each ECUPACK equipment packet contains the data from the DPACK update packet intended for a particular electronic equipment item (here the first electronic control unit 6 or gateway 8), that is to say the data from the packet d ECUPACKn equipment intended for this electronic equipment (with or without the computer components COMP1, COMP2, COMPi themselves depending on the embodiment concerned).
  • step E56 the computer components COMP1, COMP2, COMPi associated with the ECUPACKn equipment package are also transmitted on this occasion (step E56) from the processing unit 4 (which reads these computer components in the memory 26) to the electronic equipment concerned (first electronic control unit 6 and / or gateway 8).
  • Each electronic item of equipment concerned (from among a plurality of electronic items of equipment) thus receives an equipment package ECUPACK at step E58 (and possibly also the associated computer components COMP1, COMP2, COMPi, when these are separated. of the ECUPACK equipment package).
  • the following describes the implementation of the method for such electronic equipment (here first electronic control unit 6 or gateway 8), similar steps however being implemented in practice for other electronic equipment receiving a package of equipment. ECUPACK.
  • the electronic equipment (either here the first electronic control unit 6 or the gateway 8) can then optionally implement in step E60 a step of verifying the manufacturer certificate R.cert and the authority certificate CA .cert. It is recalled that in the example described here, these R.cert and CA.cert certificates are part of a cms type field of the ECUPACK equipment package.
  • step E60 (performed by the electronic equipment 6, 8 concerned) are similar to that performed in steps E50 and E52 described. above by the processing unit 4, and will therefore not be described in detail here.
  • step E60 In the absence of verification in step E60, the installation process within the equipment 6, 8 concerned is terminated. An error message can also be sent to the processing unit 4 (so that the processing unit 4 is informed of this problem when determining the status in step E42 described above, for example).
  • step E60 the electronic equipment 6, 8 concerned proceeds to step E62 to verify the integrity of the ECUPACKIND manifest (received within the equipment package ECUPACKIND).
  • the electronic equipment 6, 8 concerned applies a cryptographic signature verification algorithm using the public key R.Kpub to the SIG signature (ECUPACKIND) and to the ECUPACKIND manifest.
  • a digest of the ECUPACKIND manifesto is compared with the result obtained by applying to the SIG signature (ECUPACKIND) a cryptographic algorithm (here of RSA type) using the public key R.Kpub. (Remember that the validity of the R.cert certificate containing the public key R.Kpub was verified in step E60.)
  • the installation process is terminated at the level of the the electronic equipment 6, 8 concerned, possibly with sending of an error message to the processing unit 4 (so that the processing unit 4 is informed of this problem when determining the status at step E42 described above, for example).
  • step E62 In the event of a positive verification at step E62 (that is to say in the event of equality at the step of comparing the aforementioned condensate and the aforementioned result), the electronic equipment 6, 8 concerned verifies at step E64 if the VIN identifier of the vehicle 2 included in the ECUPACKIND manifest corresponds (i.e. in practice is equal) to the VIN identifier of the stored vehicle 2 (for example in a non-volatile memory ) within the electronic equipment 6, 8.
  • step E64 In the event of a positive verification at step E64 (that is to say in the event of equality between the VIN identifier indicated in the ECUPACKIND manifest and the stored identifier), the installation can continue at step E62 described now.
  • the electronic equipment 6, 8 checks this computer component COMPi.
  • the electronic equipment 6, 8 compares the hash H (COMPi) contained in the ECUPACKIND manifesto and a hash obtained by applying the hash function (here SHA256) to the component COMPi computer received. (Remember that the integrity of the ECUPACKIND manifesto was checked in step E62.)
  • step E66 In the event of a positive verification at step E66 (that is to say in the event of equality between the hash H (COMPi) contained in the ECUPACKIND manifest and the hash obtained), the verification of the computer component COMPi continues at step E68.
  • the electronic equipment 6, 8 then checks in step E68 the integrity of the COMPIND manifest of the computer component COMPi.
  • the electronic equipment 6, 8 concerned applies a cryptographic signature verification algorithm using the public key BK.Kpub to the signature SIG (COMPIND) and to the COMPIND manifest.
  • COMPIND signature SIG
  • COMPIND manifest a digest of the COMPIND manifesto and the result obtained by application to the SIG signature (COMPIND) of an algorithm cryptographic (here RSA type) using the public key BK.Kpub.
  • the public key BK.Kpub is for example stored in a non-volatile memory of the electronic equipment 6, 8 concerned.
  • the electronic equipment 6, 8 compares the hash H (CONTEN) contained in the COMPIND manifest and a hash obtained by applying the hash function (here SHA256) to the CONTEN content of the received computer component COMPi.
  • a step E70 can then be provided for waiting for the thermal engine to be put into operation, which makes it possible in practice to ensure that (thanks to the load by means of the alternator) the power supply is at a nominal level and / or can respond to a current demand and / or that all electronic equipment is in operation and / or that the COMPi computer component can be correctly installed in the relevant electronic equipment).
  • an additional electric power supply can be used (for example in parallel with the battery of the vehicle), so that step E70 is optional.
  • step E72 the installation of the computer component COMPi, this is that is to say, the storage of the computer component COMPi in a non-volatile (rewritable) memory with a view to its subsequent use.
  • the installation of the computer component COMPi is carried out within the electronic equipment itself (here the first electronic control unit 6) which has set up. performs the preliminary verification steps E60 to E68 described above.
  • the electronic equipment here the gateway 8
  • the electronic equipment responsible for the installation, and having in this context performed the preliminary verification steps E60 to E68, command the installation of the computer component COMPi within another electronic device, here the second electronic control unit 10.
  • the gateway 8 thus controls, for example, the storage of the computer component COMPi in a non-volatile (rewritable) memory of the second electronic control unit 10.
  • a step E74 can be used to wait for the operation of the heat engine to stop.
  • the processing unit 4 displays on a user interface (for example a screen placed in the passenger compartment vehicle 2) an indication that computer components have been installed and are ready to be used (step E76).
  • a user interface for example a screen placed in the passenger compartment vehicle 2
  • the processing unit 4 then waits at step E78 for a response from the user (for example the driver of the vehicle 2), for example via the aforementioned user interface (possibly the aforementioned screen when this screen is displayed. touch).
  • step E72 In the event of a negative response from the user, the component (s) computer (s) installed in step E72 is (are) not used.
  • the processing unit 4 transmits, to the various electronic equipment items concerned (here the first electronic control unit 6 and, via the gateway 8, the second electronic control unit 10), a CMD command for activating the computer components installed (step E80).
  • instructions included in the relevant computer component can then be executed by the processor of the electronic equipment 6, 10 in which the computer component has been installed.
  • data included in the relevant computer component can be manipulated by the processor of the electronic equipment 6, 10 in which the computer component has been installed.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Un support mémoire comprend des moyens de communication aptes à établir une communication avec une unité de traitement d'un véhicule et une mémoire (26) dans laquelle sont stockés: - au moins deux structures de données (DPACK1, DPACK2) lisibles chacune par ladite unité de traitement lorsque ladite communication est établie; - au moins deux composants informatiques (COMP) respectivement associés aux deux structures de données (DPACK1, DPACK2); - des métadonnées (INDEX) comprenant, pour chacune desdites structures de données (DPACK1, DPACK2), un condensat de référence associé à la structure de données concernée; et - une signature (SIG(INDEX)) des métadonnées. Un procédé d'installation de composants informatiques au sein d'un véhicule et un procédé de préparation d'un support mémoire sont également décrits.

Description

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

Claims

REVENDICATIONS
1. Support mémoire (20) comprenant des moyens de communication (22, 24) aptes à établir une communication avec une unité de traitement (4) d’un véhicule (2) et une mémoire (26) dans laquelle sont stockés :
- au moins deux structures de données (DPACK1 , DPACK2) lisibles chacune par ladite unité de traitement (4) lorsque ladite communication est établie ;
- au moins deux composants informatiques (COMP1 ; COMP) respectivement associés aux deux structures de données (DPACK1 , DPACK2) ;
- des métadonnées (INDEX) comprenant, pour au moins une desdites structures de données (DPACK1 , DPACK2), un condensât de référence associé à la structure de données concernée ; et
- une signature (SIG(INDEX)) des métadonnées.
2. Support mémoire selon la revendication 1 , dans lequel au moins une desdites structures de données (DPACK1 ) contient deux paquets de données (ECUPACK1 , ECUPACK2) respectivement destinés à deux équipements électroniques (6, 8) du véhicule (2).
3. Support mémoire selon la revendication 1 ou 2, dans lequel au moins une desdites structures (DPACK1 ) comprend un paquet d’équipement (ECUPACK) associé à l’un desdits composants informatiques (COMP1 ).
4. Support mémoire selon la revendication 3, dans lequel le paquet d’équipement (ECUPACK) comprend un identifiant (VIN) de véhicule.
5. Procédé d’installation de composants informatiques au sein d’un véhicule (2), comprenant les étapes suivantes :
- établissement (E30) d’une communication entre une unité de traitement (4) du véhicule et un support mémoire (20) conforme à l’une des revendications 1 à 4 en utilisant lesdits moyens de communication (22, 24) ;
- transfert (E32) des métadonnées (INDEX) et de la signature (SIG(INDEX)) des métadonnées du support mémoire (20) à l’unité de traitement (4) via la communication établie ;
- vérification (E34) de la signature (SIG(INDEX)) des métadonnées sur la base des métadonnées transférées ;
- pour chaque structure de données (DPACK1 ; DPACK2), transfert (E36) de la structure de données concernée du support mémoire (20) à l’unité de traitement (4) via la communication établie, détermination d’un condensât calculé sur la base de la structure de données reçue, et comparaison (E38) du condensât calculé et du condensât de référence associé à la structure de données concernée (DPACK1 ; DPACK2).
6. Procédé selon la revendication 5, dans lequel la structure de données concernée comprend un paquet d’équipement (ECUPACK), le procédé comprenant en outre, en cas de comparaison positive, une étape de transmission (E56) du paquet d’équipement (ECUPACK) à destination d’un équipement électronique (6 ; 8) du véhicule (2).
7. Procédé selon la revendication 6, dans lequel l’équipement électronique (6 ;
8) commande (E72) la mémorisation, dans une mémoire non-volatile, d’un composant informatique (COMPi) associé au paquet d’équipement (ECUPACK).
8. Procédé selon la revendication 5 prise dans la dépendance de la revendication 2, comprenant, en cas de comparaison positive, des étapes de transmission de chacun des deux paquets de données (ECUPACK1 , ECUPACK2) à l’équipement électronique (6 ; 8) auquel le paquet de données concerné est destiné.
9. Procédé de préparation d’un support mémoire (20) conforme à l’une des revendications 1 à 4, comprenant les étapes suivantes :
- stockage (E0) d’une pluralité de composants informatiques (COMP1 , COMP2, COMPi, COMPx) dans une module de stockage (S) ;
- réception (E12) d’un ensemble de données comprenant lesdites structures de données (DPACK1 , DPACK2), lesdites métadonnées (INDEX) et ladite signature (SIG(INDEX)) ;
- lecture (E14) des composants informatiques (COMP1 ; COMP) associés auxdites structures de données (DPACK1 , DPACK2) dans le module de stockage (S) ;
- écriture (E18), dans la mémoire (26) du support mémoire (20), des données dudit ensemble et desdits composants informatiques lus.
10. Procédé selon la revendication 9, comprenant une étape de réception (E0) d’au moins un composant informatique de ladite pluralité indépendamment de l’étape de réception (E12) de l’ensemble de données.
EP20731502.9A 2019-06-18 2020-06-15 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 Pending EP3987741A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1906551A FR3097662B1 (fr) 2019-06-18 2019-06-18 Support mémoire, procédé d’installation de composants informatiques au sein d’un véhicule et procédé de préparation d’un support mémoire
PCT/EP2020/066430 WO2020254221A1 (fr) 2019-06-18 2020-06-15 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

Publications (1)

Publication Number Publication Date
EP3987741A1 true EP3987741A1 (fr) 2022-04-27

Family

ID=68072734

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20731502.9A Pending EP3987741A1 (fr) 2019-06-18 2020-06-15 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

Country Status (3)

Country Link
EP (1) EP3987741A1 (fr)
FR (1) FR3097662B1 (fr)
WO (1) WO2020254221A1 (fr)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9141372B1 (en) * 2014-06-20 2015-09-22 GM Global Technology Operations LLC Secure and interruptible transfer of a map update package to a navigation device
US10171478B2 (en) * 2016-06-30 2019-01-01 Faraday & Future Inc. Efficient and secure method and apparatus for firmware update

Also Published As

Publication number Publication date
WO2020254221A1 (fr) 2020-12-24
FR3097662A1 (fr) 2020-12-25
FR3097662B1 (fr) 2023-01-27

Similar Documents

Publication Publication Date Title
US11119757B2 (en) System and method for remote ECU reprogramming
US11283601B2 (en) Update management method, update management system, and non-transitory recording medium
US12190092B2 (en) Control device and terminal device
EP2130184A2 (fr) Systeme et procede de gestion de donnees en provenance et a destination d'un vehicule automobile
CN1549959B (zh) 提供由车辆控制设备所使用的软件的方法
EP2279581A1 (fr) Procede de diffusion securisee de donnees numeriques vers un tiers autorise
FR2922702A1 (fr) Securisation de fichiers informatiques telechargeables sur un aeronef basee sur l'identite d'entites, procede d'authenfication, systeme et aeronef associes
US20260073739A1 (en) System, method, and apparatus for vehicle testing and diagnostics
JP2021082323A (ja) 更新管理方法、更新管理装置及び制御プログラム
CN113377658A (zh) 一种车辆控制器调试方法和装置
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
CN115130071B (zh) 车辆程序更新管理系统及其方法、重编程终端
EP4115593A1 (fr) Réseau et procédé de communication de véhicule
US12488642B2 (en) Method for determining actual emission values for a vehicle
JP6436123B2 (ja) 車両用情報通信システム、車両用情報通信方法、車載情報装置用プログラムおよびアプリケーションプログラム
FR3096160A1 (fr) Procédé d’installation d’un composant informatique et équipement électronique associé
FR2990667B1 (fr) Procede de gestion d'une installation electronique d'un vehicule automobile et installation electronique ainsi mise en oeuvre
WO2021023694A1 (fr) Procédé d'écriture dans une zone de données sécurisée d'un calculateur sur bus embarqué de véhicule
WO2022176240A1 (fr) Système de gestion d'informations
US11537640B2 (en) Map output device, map output system, and computer-readable storage medium including program
FR2936636A1 (fr) Module d'identification pour vehicule automobile.
FR3111447A1 (fr) Gestion de versions de logiciels embarqués à partir d’une empreinte informatique
US20250297868A1 (en) System and method for enhancing security of odometer information
FR3050594A1 (fr) Procede de connexion d'un appareil electronique a un systeme embarque de vehicule, appareil electronique et systeme embarque de vehicule associes
CN117119455A (zh) Ota安全通信系统及其通信方法

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20211123

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NISSAN MOTOR CO., LTD.

Owner name: RENAULT S.A.S

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: NISSAN MOTOR CO., LTD.

Owner name: AMPERE SAS

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20241209