EP3987741A1

EP3987741A1 - Memory medium, method for installing computer components within a vehicle and method for preparing a memory medium

Info

Publication number: EP3987741A1
Application number: EP20731502.9A
Authority: EP
Inventors: Eric Abadie; Sébastien BESSIERE; Devreese ARNAUD; Fradin BENOIT; Mayouma PACOME
Original assignee: Renault SAS; Nissan Motor Co Ltd
Current assignee: Ampere SAS; Nissan Motor Co Ltd
Priority date: 2019-06-18
Filing date: 2020-06-15
Publication date: 2022-04-27
Also published as: FR3097662B1; WO2020254221A1; FR3097662A1

Abstract

The invention relates to a memory medium comprising communication means capable of establishing a communication with a processing unit of a vehicle and a memory (26) in which are stored: - at least two data structures (DPACK1, DPACK2), each readable by the processing unit when the communication is established; - at least two computer components (COMP) respectively associated with the two data structures (DPACK1, DPACK2); - metadata (INDEX) comprising, for each of the data structures (DPACK1, DPACK2), a reference hash associated with the respective data structure; and - a signature (SIG(INDEX)) of the metadata. A method for installing computer components in a vehicle and a method for preparing a memory medium are also described.

Description

TITLE OF THE INVENTION: MEMORY MEDIA, COMPONENT INSTALLATION PROCESS

COMPUTING IN A VEHICLE AND PROCESS FOR PREPARING A MEMORY MEDIA

TECHNICAL FIELD OF THE INVENTION

The present invention relates generally to the installation of computer components in vehicles, in particular motor vehicles.

[0002] It finds a particularly advantageous application in the context of updates carried out by a professional (dealer or mechanic), but also applies to an update carried out by an individual.

[0003] It relates more particularly to a memory medium, a method for installing computer components in a vehicle and a method for preparing a memory medium.

STATE OF THE ART

[0004] In certain situations, we seek to install computer components in electronic equipment fitted to a vehicle. This is particularly the case when it is desired to update software running within electronic equipment or data handled by electronic equipment.

[0005] In practice, several electronic items of equipment may be affected by an update campaign. Moreover, when it is decided to update a vehicle, it is common for several update campaigns to be carried out.

PRESENTATION OF THE INVENTION

[0006] In this context, 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:

at least two data structures each readable by said processing unit when said communication is established;

- at least two computer components respectively associated with the two data structures; metadata comprising, for at least one (and possibly for each) of said data structures, a reference digest associated with the data structure concerned; and

- a signature of the metadata.

[0007] Thus, thanks to the invention, 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.

[0008] 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.

[0009] Other advantageous and non-limiting characteristics of the process according to the invention, taken individually or in any technically possible combination, are as follows:

- at least one of said data structures contains two data packets respectively intended for two electronic equipment items of the vehicle;

[0011] at least one of said structures comprises an equipment package associated with one of said computer components;

[0012] - the equipment package includes a vehicle identifier.

[0013] The invention also proposes a method for installing computer components in a vehicle, comprising the following steps:

- establishment of a communication between a vehicle processing unit and a memory medium as proposed above using said communication means;

- transfer of metadata and signature of metadata from the storage medium to the processing unit via the established communication;

- verification of the signature of the metadata on the basis of the transferred metadata;

- for each data structure, transfer of the data structure concerned from the memory medium to the processing unit via communication established, determining a hash calculated on the basis of the received data structure, and comparing the calculated hash and the reference hash associated with the data structure concerned.

[0014] 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.

[0015] The electronic equipment can then control the storage, in a non-volatile memory, of a computer component associated with the equipment package.

[0016] 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.

Finally, the invention proposes a process for preparing a memory medium as proposed above, comprising the following steps:

- storage of a plurality of computer components in a storage module;

- receiving a set of data comprising said data structures, said metadata and said signature;

reading of the computer components associated with said data structures in the storage module;

writing, in the memory of the memory medium, of the data of said assembly and of said read computer components.

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.

[0019] Of course, the different characteristics, variants and embodiments of the invention can be associated with each other in various combinations insofar as they are not incompatible or mutually exclusive.

DETAILED DESCRIPTION OF THE INVENTION

The description which follows with reference to the accompanying drawings, given by way of of non-limiting examples, will make it clear what the invention consists of and how it can be implemented.

In the accompanying drawings:

[0022] Figure 1 shows schematically a system in which the invention can be implemented;

[0023] 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;

[0025] FIG. 4 shows an example of the architecture used for an update packet stored in this memory;

[0026] 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;

[0027] FIG. 6 schematically shows a method of preparing the memory medium of FIG. 2 with an organization of the data according to FIG. 3;

[0028] Figure 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.

The vehicle 2 comprises a processing unit 4, a first electronic control unit 6, a gateway 8 and a second electronic control unit 10.

[0032] 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.

The electronic equipment mentioned above (processing unit 4, first electronic control unit 6, gateway 8 and second unit control electronics 10) 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).

[0034] 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.

As shown schematically in Figure 1, 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. To do this, 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.

[0037] The vehicle 2 further comprises a connector 12 connected to the processing unit 4 for connection to the memory medium 20, as explained below.

As shown in Figure 2, 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.

Here, 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.

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 .

Once this communication is established, 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.

Likewise, 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).

Various digital signatures (in English "digital signatures") are used in the following. To simplify the presentation, the term “signature” is used hereinafter simply to designate any digital signature.

For each type of signature used, a public key infrastructure (or PKI for "Public Key Infrastructure") is set up. In such a public key infrastructure, a public key (intended to be distributed) and a private key (kept secret by the signing entity) are conventionally associated.

In such a context, 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.

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.

As described in detail below, 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).

In practice, 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). As a variant, 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:

- INDEX metadata relating to the DPACK1 update packages, DPACK2, DPACK3 and, here, to other elements described below (TLS orchestration tools, HMI interface data, PREDAT1, PREDAT2, PREDAT3 introduction data blocks);

A SIG (INDEX) signature of these INDEX metadata;

[0053] - TLS orchestration tools (for example executable files or drivers) which may possibly be used by the processing unit 4 to process the DPACK1, DPACK2, DPACK3 update packets;

[0054] - 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).

[0057] 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.

With reference to FIG. 4, an example of an architecture used for a DPACK update packet will now be described. Each of the DPACK1, DPACK2, DPACK3 update packages already mentioned is built according to this architecture so that it can be processed by the processing unit 4.

As visible in Figure 4, 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.

As already indicated, 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.

The following are used in particular in the context of the description of the DPACK update package:

- a ROOT.cert root certificate containing ROOT.md metadata and a ROOT.Kpub public key associated with a ROOT.Kpriv private key;

- a CA.cert authority certificate containing CA.md metadata, a CA.Kpub public key and a CA.sig signature;

- an R.cert manufacturer certificate containing R.md metadata, an R.Kpub public key and an R.sig signature;

- a public key BK.Kpub associated with a private key BK.Kpriv.

A private key CA.Kpriv is associated with the public key CA.Kpub.

Likewise, 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).

We now describe in detail the different data structures shown in Figure 4.

Each COMP computer component to be installed comprises:

- CONTENT content comprising the data to be installed (in practice to be stored) in the electronic equipment concerned;

a 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;

- a SIG (COMPIND) signature of the COMPIND manifesto.

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.

The SIG (COMPIND) signature is obtained by applying to the COMIND manifesto a cryptographic signature algorithm using the private key BK.Kpriv.

These operations are for example carried out by a certification body for the CONTEN content (for example of the software) concerned.

Each package of ECUPACK equipment includes here:

- one or more computer component (s) COMP1, COMP2, COMPi as described above;

- 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;

- a SIG (ECUPACKIND) signature of the ECUPACKIND manifesto.

The inclusion of the 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.

[0074] As a variant however, the vehicle identifier VIN could be placed within the DPACKIND manifesto described below. In this case, it is possible to envisage transmitting (by means of the processing unit 4) 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).

[0075] According to another variant, the VIN identifier can be placed both in the DPACKIND manifesto and in the ECUPACKIND manifesto.

[0076] According to yet another variant, 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.

[0077] Here, the vehicle identifier VIN is a number uniquely associated with a vehicle, commonly referred to as VIN (for "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).

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).

These operations are for example carried out by the automobile manufacturer (or on behalf of the automobile manufacturer) when are defined the computer components to be installed for the electronic equipment concerned in a given vehicle (identified by the VIN identifier).

In practice, 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"). In this case, this field can include the SIG signature (ECUPACKIND), the CA.cert authority certificate and the R.cert manufacturer certificate.

The DPACK update package includes:

- one or more package (s) of ECUPACK1, ECUPACK2, ECUPACKn equipment as described above;

- 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 );

- a SIG (DPACKIND) signature of the DPACKIND manifesto.

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).

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).

These operations are for example carried out by the automobile manufacturer (or on behalf of the automobile manufacturer) when the electronic equipment concerned and the computer components to be installed in this electronic equipment are defined.

In practice, 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"). In this case, this field can include the SIG signature (DPACKIND), the CA.cert authority certificate and the R.cert manufacturer certificate.

We note that, in the architecture which has just been described, 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 (and therefore the DPACK update package) 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.

The use of this method is particularly advantageous when the needs for updating the vehicle 2 are defined within a first structure C (typically an establishment of the automobile manufacturer), but must be implemented by means of the memory medium 20 within a second structure G (typically a dealer or a garage) where many vehicles are likely to be updated.

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.

It is also noted that, although the 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. other steps described now (that is to say not necessarily before step E2).

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.

In embodiments such as that of FIG. 4 where 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.

In all cases, the transmission of the computer components COMP1, COMP2, COMPn is avoided at this step E10. Note that these computer components COMP1, COMP2, COMPn have on the other hand been transmitted to step E0, but once and for all; thus, a given computer component COMPi is transmitted in step E0 and it is therefore no longer necessary to transmit this given computer component COMPi each time it is to be used to update a vehicle.

[0103] The DPACK update packet is therefore received within the second structure G in step E12, without the computer components COMP1, COMP2, COMPi.

[0104] The computer components COMP1, COMP2, COMPi are then read in the storage module S in step E14.

In practice, 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.

[0106] According to a possible variant, data designating these components computer COMP1, COMP2, COMPi can be attached to the transmission performed during step E10. Thus, on receipt of the DPACK update packet without the computer components COMP1, COMP2, COMPi, 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.

[0107] 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 (integrated in the DPACK update package in the case of the embodiment of FIG. 4) can thus be written into the memory 26 of the device. memory medium 20 in step E18. To do this, 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.

[0109] Other data can in practice be entered during step E18, as described below.

[0110] 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.

[0111] 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.

[0112] As a variant, 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.

The method of FIG. 6 begins with a step E20 of obtaining a plurality of update packets DPACK1, DPACK2, DPACK3. In practice, 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).

In the case where the method is implemented within the second structure G, 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.

In other cases (for example when step E20 is performed on a design site), steps similar to steps E2 to E8 described above are used, for example, to obtain at least one update packet. DPACK1 day; DPACK2; DPACK3.

[0116] 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.

[0117] 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).

This 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. Where appropriate, 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.

[0121] 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. In certain embodiments, this private key can be the private key R. Kpriv already mentioned (and associated with the manufacturer certificate R.cert). In this case, 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).

[0122] 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.

It can be noted that 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.

When the method is implemented within the second structure G by means of the computer located in this second structure G, this computer has for example implemented steps E22 to E26 and can control the writing of data in the memory 26 at step E28.

[0125] According to another possible embodiment, 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.

[0126] Figure 7 shows schematically an example of a method of installing computer components in the vehicle 2.

[0127] 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. As already explained, 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.

[0130] 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. signature using the public key Kpub associated with the aforementioned private key Kpriv. 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).

[0131] If the SIG signature (INDEX) is not correctly verified, the method of Figure 7 is terminated without installing a computer component.

When the SIG signature (INDEX) is correctly verified, 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.

Note that the processing which follows (in particular at least some of the steps E36 to E48) 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.

In certain embodiments, the current DPACKn update packet is copied (during this step E36) into a buffer memory area (for example dedicated) of the processing unit 4. This solution is interesting in terms of that the subsequent processing (steps E38 and E40) 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. all of the computer components contained in these different update packets) would occupy too large a volume to be copied into the buffer memory area. 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).

As a variant (for example when the DPACKn update packet has a size greater than the dedicated buffer memory area), provision can however be made for the processing unit 4 to read the data from the DPACKn update packet. in memory 26 as they are processed in steps E38 and E40 described now.

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.

[0138] 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.

[0139] 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. An example of the implementation of this step is described below with reference to Figure 8.

[0140] The processing unit 4 then 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.

[0141] The processing unit 4 determines in step E44 whether all the DPACK1, DPACK2, DPACK3 update packets have been processed.

[0142] If not, the method loops to step E36 for processing another update packet as the current update packet DPACKn.

[0143] If so, the method continues at step E46 in which 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.

[0144] 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 The operator (or the owner of the vehicle, if applicable) can then disconnect the memory medium 20 from the connector 12.

[0145] 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).

[0146] Here we are dealing with the case where the 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 ).

[0147] 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).

As indicated above, the R.cert certificate is here contained in a field in cms format of the DPACK update package.

To verify the manufacturer certificate R.cert, 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). (It will be recalled that the public key CA.Kpub is part of the CA.cert certificate, also contained here in the field in the above-mentioned CMS format.) In practice, for example, we compare a digest of the signed data and the result obtained by application to the R.sig signature of a cryptographic algorithm (here of RSA type) using the public key CA.Kpub.

[0150] 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).

[0151] In the event of a positive verification in step E50 (that is to say in the event of equality at the step of comparing the aforementioned condensate and the aforementioned result), 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.

[0152] 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).

If the certificate is valid, 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).

[0154] As indicated above, the CA.cert certificate is here contained in a field in cms format of the DPACK update package.

To verify the CA.cert authority certificate, 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). In practice, for example, 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.

[0156] The public key ROOT.Kpub is for example stored (during the manufacture of the processing unit 4) in a non-volatile memory of the processing unit 4.

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).

In the event of a positive verification in step E52 (that is to say in the event of a tie at the step of comparing the aforementioned condensate and the aforementioned result), 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.

[0159] 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).

[0160] If the certificate is valid, 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.

[0161] 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).

[0162] If the certificate is valid, the processing unit 4 checks in step E54 certain parts of the DPACK update packet.

[0163] The processing unit checks in particular at step E54 the integrity of the DPACKIND manifest (included in the DPACK update package).

[0164] To do this, 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. In practice, we compare for example a digest of the DPACKIND manifesto and the result obtained by applying to the SIG signature (DPACKIND) a cryptographic algorithm (here of RSA type) using the public key R.Kpub. (It is recalled that the validity of the R.cert certificate containing the public key R.Kpub was verified in step E50.)

[0165] 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).

In the event of a positive verification at step E54 (that is to say in the event of equality at the step of comparing the aforementioned condensate and the aforementioned result), the installation process can continue with the processing of the various equipment packages ECUPACK1, ECUPACK2, ECUPACKn as explained now.

[0167] The processing of the ECUPACKn equipment package is described below by way of example, it being understood that the other equipment packages (ie several equipment packages in total) undergo the same processing.

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.

[0169] In the absence of verification (that is to say if the hash H (ECUPACKn) of the DPACKIND manifest differs from the hash obtained on the basis of the read ECUPACKn equipment package), the ECUPACKn n equipment package 'is not transmitted to the electronic equipment concerned (as described below) and the status determined in step E42 described above may signal this problem.

[0170] 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.

[0171] 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.

[0172] 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).

[0173] In the embodiments where the computer components COMP1, COMP2, COMPi are stored in the memory 26 independently of an ECUPACK equipment package, 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.

The checks of 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.

[0177] 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).

[0178] In the event of a positive verification at 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).

[0179] To do this, 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. In practice, for example, 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.)

In the absence of verification (that is to say in the event of an inequality in the step of comparing the aforementioned condensate and the aforementioned result), 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).

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.

[0182] In the absence of verification (that is to say in the event of an inequality between the VIN identifier indicated in the ECUPACKIND manifest and the stored identifier), the installation process is terminated at the level of the electronic equipment 6, 8 concerned, possibly with sending 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).

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.

[0184] The processing of a single COMPi computer component associated with the ECUPACK equipment package (whether this computer component is integrated in the ECUPACK equipment package or stored separately from the ECUPACK equipment package) is described below. In practice, several computer components (all associated with the ECUPACK equipment package) can be processed as described for the COMPi computer component.

[0185] The electronic equipment 6, 8 checks this computer component COMPi.

First of all, at step E66, 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.)

[0187] In the event of a negative check (that is to say if the H (COMPi) condensate contained in the ECUPACKIND manifest differs from the obtained condensate), the installation of the COMPi computer component is terminated, possibly with sending 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).

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.

[0189] The electronic equipment 6, 8 then checks in step E68 the integrity of the COMPIND manifest of the computer component COMPi.

To do this, 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. In practice, we compare for example 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.

[0191] The public key BK.Kpub is for example stored in a non-volatile memory of the electronic equipment 6, 8 concerned.

In the absence of verification (that is to say in the event of an inequality in the step of comparing the aforementioned condensate and the aforementioned result), the installation process of the computer component COMPi is terminated. , 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) .

[0193] In the event of a positive verification of the SIG signature (COMPIND) (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 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.

[0194] In the absence of verification (that is to say in the event of an inequality between the H (CONTEN) condensate of the COMPIND manifesto and the obtained condensate), the process of installing the computer component is terminated. COMPi, 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 ).

[0195] In the event of a positive verification (that is to say in the event of equality between the H condensate (CONTEN) of the COMPIND manifesto and the condensate obtained), the installation process continues as described now.

[0196] In the case for example where the vehicle 2 is a vehicle with a combustion engine, 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). As a variant, an additional electric power supply can be used (for example in parallel with the battery of the vehicle), so that step E70 is optional. When the heat engine is in operation (or without this condition, in particular for a vehicle without a heat engine), the electronic equipment 6, 8 concerned controls in 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.

[0198] In certain cases (for example for the first electronic control unit 6), 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.

[0199] In other cases, however (here for the gateway 8), the electronic equipment (here the gateway 8) 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.

[0200] It is planned here not to use the computer components as soon as they are installed, but when other conditions are met as described now.

[0201] When the vehicle 2 is a vehicle with a heat engine, a step E74 can be used to wait for the operation of the heat engine to stop.

When the heat engine of vehicle 2 is stationary (or that vehicle 2 does not use any heat engine), 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).

[0203] 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).

[0204] In the event of a negative response from the user, the component (s) computer (s) installed in step E72 is (are) not used.

[0205] In the event of a positive response from the user at step E78, 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).

[0206] The installed computer components are then activated (step E82).

[0207] For software computer components, 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.

[0208] For computer components formed from manipulable data, 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.

Claims

1. Memory medium (20) comprising communication means (22, 24) capable of establishing communication with a processing unit (4) of a vehicle (2) and a memory (26) in which are stored:

- at least two data structures (DPACK1, DPACK2) each readable by said processing unit (4) when said communication is established;

- at least two computer components (COMP1; COMP) respectively associated with the two data structures (DPACK1, DPACK2);

- metadata (INDEX) comprising, for at least one of said data structures (DPACK1, DPACK2), a reference hash associated with the data structure concerned; and

- a signature (SIG (INDEX)) of the metadata.

2. Memory medium according to claim 1, wherein at least one of said data structures (DPACK1) contains two data packets (ECUPACK1, ECUPACK2) respectively intended for two electronic equipment items (6, 8) of the vehicle (2).

3. Memory medium according to claim 1 or 2, wherein at least one of said structures (DPACK1) comprises an equipment package (ECUPACK) associated with one of said computer components (COMP1).

4. Memory medium according to claim 3, wherein the equipment package (ECUPACK) comprises a vehicle identifier (VIN).

5. A method of installing computer components in a vehicle (2), comprising the following steps:

- Establishment (E30) of a communication between a processing unit (4) of the vehicle and a memory medium (20) according to one of claims 1 to 4 using said means of communication (22, 24);

- transfer (E32) of the metadata (INDEX) and of the signature (SIG (INDEX)) of the metadata from the memory medium (20) to the processing unit (4) via the established communication;

- verification (E34) of the signature (SIG (INDEX)) of the metadata on the basis of transferred metadata;

- for each data structure (DPACK1; DPACK2), transfer (E36) of the data structure concerned from the memory medium (20) to the processing unit (4) via the established communication, determination of a condensate calculated on the basis of the received data structure, and comparison (E38) of the calculated hash and the reference hash associated with the data structure concerned (DPACK1; DPACK2).

6. The method of claim 5, wherein the data structure concerned comprises an equipment packet (ECUPACK), the method further comprising, in the event of a positive comparison, a step of transmitting (E56) the equipment packet ( ECUPACK) for electronic equipment (6; 8) of the vehicle (2).

7. The method of claim 6, wherein the electronic equipment (6;

8) controls (E72) the storage, in a non-volatile memory, of a computer component (COMPi) associated with the equipment package (ECUPACK).

8. Method according to claim 5 taken in the dependence of claim 2, comprising, in the event of a positive comparison, steps of transmitting each of the two data packets (ECUPACK1, ECUPACK2) to the electronic equipment (6; 8). for which the data packet concerned is intended.

9. A method of preparing a memory medium (20) according to one of claims 1 to 4, comprising the following steps:

- storage (E0) of a plurality of computer components (COMP1, COMP2, COMPi, COMPx) in a storage module (S);

- reception (E12) of a set of data comprising said data structures (DPACK1, DPACK2), said metadata (INDEX) and said signature (SIG (INDEX));

- reading (E14) of the computer components (COMP1; COMP) associated with said data structures (DPACK1, DPACK2) in the storage module (S);

- Writing (E18), in the memory (26) of the memory medium (20), of the data of said assembly and of said read computer components.

10. The method of claim 9, comprising a receiving step (E0) of at least one computer component of said plurality independently of the receiving step (E12) of the data set.