阅读说明：本技术 用于安装数据处理组件的方法以及相关联的电子设备 (Method for installing a data processing component and associated electronic device ) 是由 E·阿巴迪 S·贝塞尔 P·梅尼尔 于 2020-04-15 设计创作，主要内容包括：一种用于在装配在车辆中的电子设备中安装数据处理组件(COMP1)的方法,包括以下步骤：-接收包括清单(ECUPACKIND)的设备包(ECUPACKIND),该清单包括该数据处理组件的散列值(H(COMP1))；-验证该清单(ECUPACKIND)的完整性；-接收该数据处理组件(COMP1)；-验证该数据处理组件的散列值(H(COMP1))与所接收的数据处理组件(COMPi)之间的对应关系；-仅在该清单(ECUPACKIND)的完整性通过验证且该对应关系通过验证的情况下安装该数据处理组件(COMP1)。还描述了一种相关联的电子设备。(A method for installing a data processing component (COMP1) in an electronic device fitted in a vehicle, comprising the steps of: -receiving a device package (ECUPACKIND) comprising a list (ECUPACKIND) comprising a hash value (H (COMP1)) of the data processing component; -verifying the integrity of the list (ECUPACKIND); -receiving the data processing component (COMP 1); -verifying the correspondence between the hash value (H (COMP1)) of the data processing component and the received data processing Component (COMPi); -installing the data processing component (COMP1) only if the integrity of the list (ecetackidd) is verified and the correspondence is verified. An associated electronic device is also described.)

1. A method for installing a data processing component (COMP1) in an electronic device (6; 10) provided in a vehicle (V), the method comprising the steps of:

-receiving (E18) a device package (ecuack) comprising a first list (ecupcikind) comprising a hash value (H (COMP1)) of the data processing component;

-verifying (E22) the integrity of the first list (ecupackidd);

-receiving (E32) the data processing component (COMP 1);

-verifying (E34) a correspondence between the hash value (H (COMP1)) of the data processing component and the received data processing component (COMP 1);

-installing (E40) the data processing component (COMP1) only if the integrity of the first manifest (ecepacackind) is verified and the correspondence is verified.

2. The method of claim 1, wherein the first list (ECUPACKIND) includes a first Vehicle Identifier (VIN), and the method comprises the steps of:

-comparing (E24) the first Vehicle Identifier (VIN) with a second vehicle identifier stored in the vehicle (V);

-installing (E40) the data processing component (COMP1) only if the comparison of the first identifier (VIN) with the second identifier is positive.

3. The method of claim 1 or 2, wherein the device package (ECUPACK) comprises a first signature (SIG (ECUPACKIND)), and wherein the integrity of the list (ECUPACKIND) is verified by applying a cryptographic signature verification algorithm to the first signature (SIG (ECUPACKIND)) and the first list (ECUPACKIND).

4. Method according to one of claims 1 to 3, wherein the data processing component (COMP1) is received independently of the device packet (ECUPACK).

5. Method according to one of claims 1 to 3, wherein the data processing component (COMP1) is received within the device pack (ECUPACK).

6. The method according to one of claims 1 to 5, comprising the steps of:

-receiving (E8) a container (GLOB) comprising the device package (ecuack) and a second list (DPACKIND);

-verifying (E14) the integrity of the second manifest (DPACKIND).

7. The method of claim 6, wherein the container (GLOB) comprises a further equipment package (ECUPACK2) intended for a further electronic device.

8. The method of claim 6 or 7, wherein the second manifest (DPACKIND) includes a first Vehicle Identifier (VIN), and the method comprises the steps of:

-comparing (E12) the first Vehicle Identifier (VIN) with a second vehicle identifier stored in the vehicle (V);

-transmitting (E16) the device package (eceppack) only if the comparison of the first identifier (VIN) with the second identifier is positive.

9. The method of one of the claims 6 to 8, wherein the container (GLOB) is received from a remote server (S) in response to a Request (REQ) transmitted by the vehicle (V).

10. The method of one of the claims 6 to 8, wherein the container (GLOB) is received from a memory card (20) inserted into a card reader (12) provided in the vehicle (V).

11. Method according to one of claims 1 to 10, wherein the data processing component (COMP1) comprises a second signature (sig (compound)) and content (content), and wherein the method comprises a step (E36) of verifying the integrity of the content (content) using the second signature (sig (compound)).

12. An electronic device (6; 8) intended to be arranged in a vehicle and comprising:

-means for receiving a device package (ECUPACK) comprising a list (ECUPACKIND) comprising hash values (H (COMPi)) of data processing components;

-a module for verifying the integrity of the list (ECUPACKIND);

-a module for receiving the data processing Component (COMPi);

-a module for verifying the correspondence between the hash value (h (COMPi)) of the data processing component and the received data processing Component (COMPi);

-an installation module configured to install the data processing Component (COMPi) only if the integrity of the manifest (ecetackidd) is verified and the correspondence relationship is verified.

13. The electronic device (6; 8) of claim 12, wherein the list (ECUPACKIND) comprises a first Vehicle Identifier (VIN) and the electronic device comprises:

-means for comparing the first Vehicle Identifier (VIN) with a second identifier of the vehicle (V) stored within the vehicle (V),

wherein the installation module is configured to install the data processing Component (COMPi) only if the integrity of the list (ecapacckind) is verified, the comparison of the first identifier (VIN) with the second identifier is positive and the correspondence is verified.

Technical Field

The present invention relates generally to mounting data processing assemblies in vehicles, particularly motor vehicles.

The invention is particularly advantageous in the context of downloading such data processing components into a vehicle, but also in the case of loading the data processing components locally into the vehicle, for example from a memory card.

More particularly, the invention relates to a method for mounting a data processing component and an associated electronic device.

Background

In some cases, it is desirable to install a data processing component in an electronic device provided in a vehicle. This is particularly true when it is desired to update software implemented within the electronic device or data manipulated by the electronic device.

The installation of such data processing components naturally has an effect on the subsequent operation of the vehicle and must be carried out in a controlled manner.

Disclosure of Invention

Against this background, the invention proposes a method for installing a data processing assembly in an electronic device provided in a vehicle, the method comprising the steps of:

-receiving a device package comprising a first manifest, the first manifest comprising hash values of the data processing components;

-verifying the integrity of the first manifest;

-receiving the data processing component;

-verifying a correspondence between the hash value of the data processing component and the received data processing component;

-installing the data processing component only if the integrity of the first manifest is verified and the correspondence relationship is verified.

In this way, as a result of the invention, the vehicle receives a data structure associated with the data processing component and participating (in particular by using the hash value) in the verification of the integrity of the data processing component. The proposed solution further makes it possible to transmit the package of devices and the data processing component itself separately, which provides greater flexibility during the design of the vehicle and its electronics.

Further, the above first list may include a first vehicle identifier, and then the installation method may include the steps of:

-comparing the first vehicle identifier with a second vehicle identifier stored within the vehicle;

-installing the data processing component only if the comparison of the first identifier with the second identifier is positive.

The following are other non-limiting advantageous features of the method according to the invention, considered individually or according to all technically possible combinations:

-the device package comprises a first signature;

-verifying the integrity of the manifest by applying a cryptographic signature verification algorithm to the first signature and the first manifest;

-the data processing component is received independently of the device package;

-the data processing component is received within the device package;

-the data processing component comprises a second signature and content;

-the method comprises the step of verifying the integrity of the content using the second signature.

The method may further comprise the steps of:

-receiving a container comprising the equipment package and a second manifest;

-verifying the integrity of the second manifest.

The second list may thus comprise the first vehicle identifier, and the installation method may in this case comprise the steps of:

-comparing the first vehicle identifier with a second vehicle identifier stored within the vehicle;

-transmitting the device package only if the comparison of the first identifier with the second identifier is positive.

The container may thus comprise another device package intended for another electronic device, for example.

The container may be further received from a remote server in response to a request transmitted by the vehicle (e.g., directly via a communication established between the remote server and the vehicle, the communication capable of being partially using a wireless link between the vehicle and a cellular telephone network); in a variant, the container may be received from a memory card inserted into a card reader provided in the vehicle.

Finally, the invention relates to an electronic device intended to be arranged in a vehicle and comprising:

-means for receiving a device package comprising a manifest, the manifest comprising hash values of the data processing components;

-a module for verifying the integrity of the manifest;

-a module for receiving the data processing component;

-means for verifying a correspondence between the hash value of the data processing component and the received data processing component;

-an installation module configured to install the data processing component only if the integrity of the manifest is verified and the correspondence is verified.

Further, the manifest may include a first vehicle identifier, and the electronic device may therefore include means for comparing the first vehicle identifier with a second identifier of the vehicle stored within the vehicle.

The installation module may be configured to install the data processing component only if the integrity of the manifest is verified, the comparison of the first identifier with the second identifier is positive and the correspondence is verified.

The use of the target vehicle identifier in the manifest enables increased legitimacy protection in addition to the integrity and authenticity protection provided by performing manifest verification. This is because while the on-board update process can of course verify that the received image is undamaged, authentic and compatible on certain hardware, this does not necessarily mean that the vehicle can legitimately receive the image. In the event of a network attack or malicious process in the end-to-end transmission chain, images of compatible vehicles may be inserted in place of the source images. Thus, the vehicle identifier in the manifest will allow preventing any fraud from occurring in this scenario.

Such an electronic device is, for example, an electronic control unit (or computer) comprising a processor and a memory storing computer program instructions executable by the processor.

In this case, the above-mentioned modules are implemented, for example, by cooperation of the processor and specific instructions configured to implement the functions pertaining to the module in question (as described below) when executed by the processor.

Of course, the various features, variations and embodiments of the invention may be interrelated in various combinations so long as they are not incompatible or mutually exclusive.

Detailed Description

The description, given by way of non-limiting example with reference to the accompanying drawings, will make it easy to understand what the invention relates to and how it may be carried out.

In the drawings:

FIG. 1 schematically illustrates a system in which the present invention may be implemented;

FIG. 2 illustrates an example of data organization that may be used in the context of the present invention;

FIG. 3 illustrates another example of data organization that may be used in the context of the present invention; and

fig. 4 shows an example of a method for installing a data processing assembly in a vehicle according to the invention.

The system of fig. 1 includes a vehicle V (e.g., a motor vehicle), a mobile phone network N, a wide area network I (such as the internet), and a remote server S.

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

Fig. 1 shows the elements of the vehicle V that are advantageous for understanding the invention, but in practice the vehicle V naturally comprises other elements, in particular other electronic control units or processors.

The aforementioned electronic devices (communication unit 2, processing unit 4, first electronic control unit 6, gateway 8 and second electronic control unit 10) may in practice each be produced in the form of a microprocessor architecture; in particular, in this context, each of these electronic devices includes a processor and at least one memory (e.g., RAM and/or non-volatile memory).

The processing unit 4 itself may in practice be implemented by an electronic control unit, which has more functions than described below, where applicable.

As schematically illustrated in fig. 1, the processing unit 4 is connected to the communication unit 2, the first electronic control unit 6 and the gateway 8, so as to be able to exchange data with these different electronic devices. For this purpose, the communication unit 2, the processing unit 4, the electronic control unit 6 and the gateway 8 are connected, for example, to a (same) onboard data processing network (not shown), for example a CAN bus ("controller area network").

The gateway 8 is further connected to a second electronic control unit 10, for example by means of a dedicated bus.

The vehicle V may further include a card reader 12 for the memory card 20, which may be used in a construction variant of the invention, as described below.

The communication unit 2 is configured to implement a communication C in the mobile phone network N (as schematically illustrated by a solid line in fig. 1, which indicates that the connection is of a physical type, e.g. 3G/4G, Wi-Fi, etc.), and thus a connection to the remote server S can be established through the mobile phone network N (in particular by using a wireless link between the vehicle V and a cellular phone network being part of the mobile phone network N) and the wide area network I, so that the processing unit 4 and the remote server S can exchange data D (as schematically illustrated by a dashed line in fig. 1, which indicates that the connection is of a logical type), in particular in the context of installing data processing components within the vehicle V, as described below.

Fig. 2 shows an example of data organization that may be used in the context of the present invention.

These data comprise in particular data processing components COMP1, COMP2, COMPi intended to be installed in one or more electronic devices of the vehicle V (in this case in particular in the first electronic control unit 6 and/or in the second electronic control unit 10, both of which are referred to using the term "electronic devices" in this example).

In this case, the data processing components COMP1, COMP2, COMPi are encapsulated within a tree structure, as follows:

-the download package DPACK comprises one or more device packages ECUPACK1, ECUPACK2, ECUPACK, each device package being associated with an electronic device of the vehicle V;

each device package eccupack comprises data related to one or more data processing components COMP1, COMP2, COMPi intended for a specific electronic device.

This tetris nesting child type packaging approach is particularly advantageous because it ensures consistency of updates within the same electronic component, in addition to enabling content isolation per target component, that is, here per electronic control unit 2, 4, 6, 8 and 10 (whose software can be modified by remote updates (or over-the-air firmware upgrade FOTA)). Further, such packaging enables multiple levels of integrity/authenticity verification with multiple stages. More specifically, the communication unit 2 will be able to perform a first level of authentication on the download packet DPACK and, once authenticated, extract and distribute the device packet(s) ECUPACK to the target components 2, 4, 6, 8 and 10. Thus, the target components 2, 4, 6, 8, and 10 will be able to use different cryptographic hardware for level 2 authentication, which enables per-component content isolation to be produced (content may have many providers). After the device package(s) ECUPACK is authenticated, the data processing components COMP1, COMP2, COMPi may be extracted, further subjected to a third password level verification, and finally installed if verified. The procedure is therefore particularly advantageous in the case where the target processor is the communication unit 2, since for such communication units, which typically consist of a secure or protected area (or trusted area) and an insecure area (or untrusted area), the method thus enables it to perform two levels of authentication as a remote processor: verifying the DPACK in the untrusted connecting area; the device package ECUPACK is extracted and shared with the trusted zone, and then device package validation is performed in the trusted zone. In this way, ultimately, the method enables multiple levels of authentication, whether the target ECU is local or remote (other ECUs of the vehicle network). In an alternative, additionally shown in fig. 2, component COMP, which is not in the device packet ECUPACK, will be received by the second exchange procedure and verified by the hash values H (COMP1), H (COMP2), H (COMP). Packaging the update content in a component enables control of the manufacturer-level electronic signature to ensure authentication of the image and thus control of deployment. Such signing operations of the components will be performed manually at the vehicle manufacturer, for example by an authenticated security agent (with specific privileges). Without this operation, undamaged content cannot be deployed on the vehicle. This signature level is for example manual (in particular ASSIM signatures) and enables control of the deployment authorization. In this way, the uncorrupted and authentic binary update content provided by the supplier will not be available to the processor 2, 4, 6, 8 or 10 without this level of verification, which makes it possible to ensure that only images certified by the vehicle manufacturer can be transmitted to the vehicle. This further ensures the quality of the target software prior to deployment.

Each of these data packets contains a digital signature for installing the data processing component, as described below. As envisaged below, the verification of a digital signature requires a specific cryptographic infrastructure, which will be described herein.

For simplicity of presentation, any digital signature is hereinafter referred to simply as a "signature".

The following applies in particular:

-a root certificate root.cert containing metadata root.md and a public key root.kpub associated with a private key root.kpriv;

-an authorization certificate, ca.cert, containing metadata, ca.md, a public key, ca.kpub, and a signature, ca.sig;

-a manufacturer certificate r.cert containing metadata r.md, a public key r.kpub and a signature r.sig;

-a public key bk.kpub associated with a private key bk.kpriv.

The private key ca.kpriv is associated with the public key ca.kpub.

In the same way, the private key r.kpriv is associated with the public key r.kpub.

In this case, the term "associated public and private keys" is intended to be understood to refer to public and private keys that are associated in a "public key infrastructure" (or PKI).

In this context, a set of data may be signed by applying to it a cryptographic signature algorithm using a private key (in this case a cryptographic signature algorithm of the RSA type); the signature can then be verified by an associated cryptographic signature verification algorithm (in this case also a cryptographic signature verification algorithm of the RSA type) using the public key associated with the private key described above.

The signature ca.sig of the certificate of authority ca.cert is obtained by applying a cryptographic signature algorithm using the private key root.kpriv to the group formed by the metadata ca.md and the public key ca.kpub (this operation is performed, for example, by a certificate authority).

The signature r.sig of the manufacturer certificate r.cert itself is obtained by applying a cryptographic signature algorithm using the private key ca.kpriv to the group formed by the metadata r.md and the public key r.kpub (this operation can also be performed by the certificate authority described above).

The various data structures shown in fig. 2 will now be described in detail.

Each data processing component COMP to be installed comprises:

content, which comprises data to be installed (actually stored) in the electronic device in question;

a manifest compound containing, in particular, the hash value h (content) of the content to be installed and, where applicable, a description of the data processing component, e.g. of the function updated by this component;

-signature sig (compound) of the manifest compound.

These data to be installed may constitute software or software components (e.g., software updates). The software or software components are thus configured to be executed at least partly by the processor of the electronic device in question. In a variant, these data to be installed may be data (e.g. map data) to be stored for subsequent manipulation by the processor of the electronic device in question.

The hash value h (content) is obtained by applying a hash value function (e.g., a hash value function of the SHA-256 type) to the content.

The signature sig (combined) is obtained by applying a cryptographic signature algorithm using the private key bk.

These operations are performed, for example, by the certifying body of the content (e.g. software) in question.

In this case, each device packet ecuack includes:

-one or more data processing components COMP1, COMP2, COMPi as described above;

a list ecepcink comprising the hash values H (COMP1), H (COMP2), H (COMP), and (where applicable) the vehicle identifier VIN of each data processing component COMP1, COMP2, COMPi contained in the device package ecepck and/or a description of the data processing components COMP1, COMP2, COMPi contained in the data package;

-a signature sig (ecapackind) of the list ecapockind.

A variety of variations for providing an identifier VIN may be implemented. Including the identifier VIN in the device package ECUPACK as described above makes it possible to ensure that the data processing component (e.g. the processor of the vehicle) installed in the electronic device is indeed a component belonging to the vehicle. This is because one assembly is likely to be suitable for a large number of vehicles of the same type, which gives the user the possibility to e.g. replace the processor of his vehicle with the processor of another vehicle of the same type. Including the VIN identifier in the device package ECUPACK enables avoiding such manipulations.

However, in a variant, such a manoeuvre may still be authorized, for example by placing the vehicle identifier VIN in the list DPACKIND described below, as is the case in the variant shown in fig. 3. In this case, it can be envisaged that the transmission (using the processing unit 4) of the device package eceppack to the electronic device in question is only made in the event of a positive comparison of the received identifier VIN within the list DPACKIND with the stored identifier of the vehicle V (in this case, within the processing unit 4).

According to other embodiments that may be envisaged, the identifier VIN may be placed in both the list DPACKIND and the list ecuupackind, or not in either of these lists, in particular for data processing components that are compatible with any vehicle, such as data processing components that are map data comprising a navigation system.

In this case, the identifier VIN of the vehicle V is a number uniquely associated with the vehicle, commonly referred to as the VIN "vehicle identification number".

The hash values H (COMP1), H (COMP2), H (COMP) are obtained by applying a hash function (e.g. of the SHA-256 type) to the data constituting the data processing components COMP1, COMP2, COMP, respectively, for example during the definition of the equipment package eccupack (according to the requirements of the device in question, in particular the update requirements of the device).

The signature sig (ecapackind) is obtained by applying to the list ecapockind a cryptographic signature algorithm using the private key r.kpriv (associated with the manufacturer certificate r.cert).

These operations are performed, for example, by the vehicle manufacturer (or on behalf of the vehicle manufacturer) when defining the data processing components to be installed for the electronic device in question (identified using the identifier VIN) in a particular vehicle.

In practice, the signature sig (ecuckind) is contained, for example, in a field dedicated to the device packet ecuack, for example in a field of cms format ("cryptographic message syntax"). In this case, the field may include a signature sig (ecapcind), an authorization certificate ca.

The download packet DPACK includes:

-one or more device packages as described above, ECUPACK1, ECUPACK2, ECUPACKn;

the list DPACKIND comprises in particular the hash value H (ECUPACK1), H (ECUPACK2) of each device packet ecuck 1, ECUPACK2, ecuckn contained in the download packet DPACK and, where applicable, a description of the device packets ECUPACK1, ECUPACK2, ecuckn contained in the download packet DPACK (for example, an indication of each device packet ECUPACK1, ECUPACK2, ecuckn of the target electronic device of the device packet in question);

-signature sig of manifest DPACKIND (DPACKIND).

The hash values H (ecup ack1), H (ecup ack2), H (ecup ackn) are obtained by applying a hash function (e.g. of SHA-256 type) to the device packets ecup 2, ecup ack2, ecup ackn in question, respectively, for example during the definition of the download packet DPACK (after the definition of the respective requirements of the target electronic device and each device).

The signature sig (DPACKIND) is obtained by applying a cryptographic signature algorithm using the private key r.kpriv (associated with the manufacturer certificate r.cert) to the manifest DPACKIND.

These operations are performed, for example, by (or on behalf of) the vehicle manufacturer when defining the electronic devices in question and the data processing components to be installed in these electronic devices.

In practice, the signature sig (dpackind) is contained, for example, in a dedicated field of the download packet DPACK, for example in a field of cms format ("cipher message syntax"). In this case, the field may include a signature sig (dpackind), an authorization certificate ca.

It should be noted that in the above-described architecture, each of the data processing components COMP1, COMP2, COMPi is independent of the installation-target vehicle V (and may be used, for example, for a fleet of vehicles). However, the device packages ECUPACK1, ECUPACK2, ECUPACKn (and thus the download package DPACK) are configured specifically for the vehicle V.

Fig. 3 has a variant that can be envisaged for the data organization within the download packet DPACK.

As already indicated, in this variant, the vehicle identifier VIN is placed within the list DPACKIND.

Furthermore, the data processing components COMP1, COMP2, COMPi related to a particular electronic device are not included in the device package ECUPACK1 intended for that electronic device, but are relatively outside the device package so as to be able to be transmitted separately from the device package ECUPACK1, if applicable, as will be explained below.

In this case, the device package ecuack 1 includes:

-a list ECUPACKIND comprising hash values H (COMP1), H (COMP2), H (COMP) of each of the data processing components COMP1, COMP2, COMPi associated with the electronic device in question;

-a signature sig (ecapackind) of the list ecapockind.

An example of a method for installing a data processing assembly in a vehicle V according to the invention will now be described with reference to fig. 4.

The method starts in a step E2, during which the processing unit 4 transmits a request REQ intended for a remote server S. From this request, the vehicle V attempts to determine whether a data processing component is available for installation in the vehicle V, for example, for updating a specific software component or specific data (such as map data).

The request REQ is transmitted, for example, periodically by the processing unit 4. In practice, the electronic coordinates of the remote server S are stored, for example, in the processing unit 4 and are used to transmit a request REQ intended for the remote server S. The electronic coordinates preferably refer to a secure connection, such as SSL (secure sockets layer).

The request REQ may include an identifier VIN of the vehicle V.

The remote server S receives the request REQ in step E4 and determines (e.g. based on the identifier VIN included in the request REQ) whether the data processing component is available for the vehicle V download.

In this case it is assumed that the data processing components are available for download and installation in the vehicle V. Thus, the server S transmits the global container GLOB to the processing unit 4 in step E6.

The global container GLOB includes a list DPACKIND, an associated signature sig (DPACKIND), and device packages ecuack 1, ecuack 2, ecucakn. Thus, according to embodiments, the global container GLOB includes or does not include data processing components COMP1, COMP2, COMPi.

This is because, according to the first embodiment, it is also possible to transmit all or part of the data processing components COMP1, COMP2, COMPi in this step E6 (these components transmitted in step E6 are therefore not transmitted in step E26 as described below). These data processing components may thus be transmitted within the device package ecepack (e.g. within the framework of the data structure illustrated in fig. 2) or together with the device package ecepack 1 in question (e.g. within the framework of the data structure illustrated in fig. 3).

According to a second embodiment, the global container GLOB transmitted at step E6 does not contain any of the data processing components COMP1, COMP2, COMPi (which are thus transmitted during one or more steps according to the E26 step described below).

The processing unit 4 receives the global container GLOB in step E8 and may thus store the global container. In this case, the global container GLOB is received directly by a communication established between the remote server S and the vehicle V, which in this case partly uses a wireless link between the vehicle V and the already mentioned cellular telephone network.

In a variant, the global container GLOB (with or without data processing components) may be received in step E8 from a memory card 20 inserted into the card reader 12 (and thus connected to the processing unit 4) as described above. In this case, steps E2 to E6 are not performed.

It should be noted that in embodiments where the transmitted global container GLOB does not contain the data processing components COMP1, COMP2, COMPi (or at least some of them), the size of the memory within processing unit 4 required for storing the received global container GLOB may be reduced. In other words, there is no need to provide a buffer memory within the processing unit 4 adapted to store the entire download packet DPACK.

The processing unit 4 thus performs in step E10 a verification of the manufacturer certificate r.cert (which in particular contains the public key r.kpub which is then used to verify the signature).

As mentioned above, in this case the certificate r.cert is contained in the cms-formatted field of the download packet DPACK (and thus the global container GLOB received in step E8).

To verify the manufacturer certificate r.cert, a cryptographic signature verification algorithm using the public key ca.kpub is applied to the signature r.sig and the signed data (in this case the metadata r.md and the public key r.kpub). (note that the public key ca.kpub is part of the certificate ca.cert itself contained in the field with the format CMS described above.) in practice, for example, the hash value of the signed data is compared with the result obtained by applying a cryptographic algorithm using the public key ca.kpub (in this case an RSA-type cryptographic algorithm) to the signature r.sig.

In case the verification is not passed (that is to say in case an inequality occurs during the step of comparing the above hash value with the above result), the installation process ends and an error message is sent to the remote server S, if applicable.

In case of a verification being passed in step E10 (that is to say in case of equality occurring in the step of comparing the above hash value with the above result), the processing unit may verify whether the certificate r.cert has not expired by comparing the date and time concerned with the expiration date and time mentioned in the metadata r.md.

If the certificate has expired, the installation process ends and an error message is sent to the remote server S if applicable.

If the certificate is valid, the processing unit 4 performs in step E12 a verification of the authorization certificate ca.cert (which contains in particular the public key ca.kpub used as described above).

Cert is in this case contained in the cms-formatted field of the download packet DPACK (and thus the global container GLOB received in step E8), as described above.

To verify the authorization certificate ca.cert, a cryptographic signature verification algorithm using the public key root.kpub is applied to the signature ca.sig and the signed data (in this case the metadata ca.md and the public key ca.kpub). In practice, for example, the hash value of the signed data is compared with the result obtained by applying a cryptographic algorithm using the public key root.kpub (in this case, an RSA-type cryptographic algorithm) to the signature ca.sig.

Kpub is stored, for example (during production of the processing unit 4), in a non-volatile memory of the processing unit 4.

In case the verification is not passed (that is to say in case an inequality occurs during the step of comparing the above hash value with the above result), the installation process ends and an error message is sent to the remote server S, if applicable.

In case of a verification being passed in step E12 (that is to say in case of equality occurring in the step of comparing the above hash value with the above result), the processing unit may verify whether the certificate ca.cert has not expired by comparing the date and time concerned with the expiration date and time mentioned in the metadata ca.md.

If the certificate has expired, the installation process ends and an error message is sent to the remote server S if applicable.

If the certificate is valid, the validity of the root certificate root.cert can be verified in the same way by comparing the date and time of a given time with the expiration date and time of the root certificate root.cert mentioned in the metadata root.md.

If the certificate has expired, the installation process ends and an error message is sent to the remote server S if applicable.

If the certificate is valid, the processing unit 4 verifies in step E14 the specific part of the global container GLOB received in step E8.

The processing unit verifies in step E14 in particular the integrity of the manifest DPACKIND (which was received in the global container GLOB).

To this end, the processing unit applies a cryptographic signature verification algorithm using the public key r.kpub to the signature sig (DPACKIND) and the manifest DPACKIND. In practice, for example, the hash value of the manifest DPACKIND is compared with the result obtained by applying a cryptographic algorithm using the public key r.kpub (in this case a cryptographic algorithm of the RSA type) to the signature sig (DPACKIND). (note that the validity of the certificate r.cert containing the public key r.kpub is verified in step E10.)

In case the verification is not passed (that is to say in case an inequality occurs during the step of comparing the above hash value with the above result), the installation process ends and an error message is sent to the remote server S, if applicable.

In the case of a verification pass in step E14 (that is to say in the case of equality occurring during the step of comparing the above hash value with the above result), the installation process continues in step E16, which will now be described.

The processing unit 4 distributes the various device packages eceppack in step E16 to the electronic device responsible for installing the data-processing components (in this case for example the first electronic control unit 6 and/or the gateway 8).

Each equipment package ECUPACK contains data of a global container GLOB intended for a specific electronic equipment (in this case the first electronic control unit 6 or the gateway 8), that is to say data of an equipment package ECUPACKn intended for an electronic equipment, with or without the data processing components COMP1, COMP2, COMPi themselves, depending on the embodiment in question.

As already indicated, all or part of the electronic components may in fact be transmitted in the global container GLOB during step E6, and thus at least some of the device packages eceppack may comprise one or more data processing components.

Thus, in step E18, each electronic device in question receives a device package ECUPACK. Although the following describes an embodiment of a method for such an electronic device (in this case the first electronic control unit 6 or the gateway 8), in practice similar steps are performed for other electronic devices receiving the device package ecepack.

The electronic device (in this case the first electronic control unit 6 or the gateway 8) can therefore, where applicable, carry out the step of verifying the manufacturer certificate r.cert and the authorization certificate ca.cert in step E20. It should be noted that in the example described in this case, these certificates r.cert and ca.cert are part of the cms type field of the device package eccupack.

The verification of step E20 (performed by the electronic device 6, 8 in question) is similar to the verification performed by the processing unit 4 in steps E10 and E12 described above and will not be described in detail here.

In case the authentication is not passed in step E20, the installation process within the item of equipment 6, 8 in question ends. An error message may further be sent to the processing unit 4 (e.g. possibly transmitted to the remote server S).

In case of a verification pass in step E20, the electronic device 6, 8 in question performs in step E22 a verification of the integrity of the list ecupackidd (which is received within the device package ecupackidd).

To this end, the electronic device 6, 8 in question applies a cryptographic signature verification algorithm using the public key r.kpub to the signature sig (eculackind) and the list eculackind. In practice, for example, the hash value of the list ecepacackind is compared with the result obtained by applying a cryptographic algorithm using the public key r.kpub (in this case a cryptographic algorithm of the RSA type) to the signature sig (ecepacackind). (Note that the validity of the certificate R.cert containing the public key R.Kpub is verified during step E20.)

In case the verification is not passed (that is to say in case an inequality occurs in the step of comparing the above hash value with the above result), the installation process at the electronic device 6, 8 in question ends and, if applicable, an error message is sent to the processing unit 4 (possibly transmitted to the remote server S, for example).

In the case of verification being passed in step E22 (that is to say equality occurring in the step of comparing the above-mentioned hash value with the above-mentioned result), the electronic device 6, 8 in question verifies in step E24 whether the identifier VIN of the vehicle V included in the list ecetackidd corresponds to (that is to say is in practice equal to) the identifier VIN of the vehicle V stored within the electronic device 6, 8 (for example in a non-volatile memory).

In case of non-passing authentication (that is to say in case the identifier VIN indicated in the list ecupcinkind is not equal to the stored identifier), the installation process at the electronic device 6, 8 in question ends and, if applicable, an error message is sent to the processing unit 4 (possibly transmitted to a remote server S, for example).

In the case of verification in step E24 (that is to say in the case where the identifier VIN indicated in the list ecepcinkind is equal to the stored identifier), the installation can be continued in step E32 described below (after reception of the data processing component, as will now be described).

In parallel with the mentioned processing performed within the electronic device 6, 8 in charge of installation, the remote server S transmits at least one data processing component COMPi in the download package DPACK to the processing unit 4 in step E26. (although this is not shown in fig. 4, the transmission of this data processing component COMPi may be initiated after the remote server S receives an indication from the processing unit 4, which indication signals that there is sufficient space in e.g. a buffer memory to store the data processing component COMPi).

Processing unit 4 receives data processing component COMPi in step E28.

The processing of the single data processing component COMPi will now be described below. In practice, a plurality of data processing components are received simultaneously or later depending on the capacity of the buffer memory of the processing unit 4 and processed as described for the data processing components COMPi.

When the component COMPi received in step E28 enables the device package ecupac kn to be supplemented (using the data of the global container GLOB), the processing unit 4 may, where applicable, carry out a verification of the content of the device package ecuckn in question in step E29, for example by comparing the hash value h (eculackn) contained in the list DPACKIND with a hash value obtained by applying a hash function (SHA 256 in this case) to the received device package ecukn.

In case of a non-passing verification (that is to say in case the hash value h (ecapackn) of the list DPACKIND is different from the hash value obtained on the basis of the received device package ecapackn), the data processing component COMPi is not transmitted to the electronic device 6, 8 in question and an error message may be sent to the remote server S if applicable.

In case of a verification pass in step E29, that is to say in case the hash value h (eculackn) of the list DPACKIND is equal to the hash value obtained on the basis of the received device package ecuckn, in step E30 the data processing component COMPi is distributed to the electronic device 6, 8 in question.

Thus, in step E32, the electronic device 6, 8 in question receives the data processing component COMPi.

Thus, the electronic device 6, 8 may authenticate the data processing component COMPi.

First, in step E34, the electronic device 6, 8 compares the hash value h (COMPi) contained in the list ecupcikind with the hash value obtained by applying a hash function (SHA 256 in this case) to the received data processing component COMPi. (Note that the integrity of the manifest ECUPACKIND was verified in step E22.)

In the case of no verification passing (that is to say in the case where the hash value h (COMPi) contained in the list ecutackidd is different from the obtained hash value), the installation of the data processing component COMPi ends.

In case of verification being passed in step E34 (that is to say in case the hash value h (COMPi) contained in the list ecupcinkind is equal to the obtained hash value), the verification of the data processing component COMPi is continued in step E36.

The electronic device 6, 8 first verifies the integrity of the list finished of data processing components COMPi in step E36.

To this end, the electronic device 6, 8 in question applies a cryptographic signature verification algorithm using the public key bk. In practice, for example, the hash value of the list compound is compared with the result obtained by applying a cryptographic algorithm using the public key bk.kpub (in this case a cryptographic algorithm of the RSA type) to the signature sig (compound).

Kpub is stored, for example, in a non-volatile memory of the electronic device 6, 8 in question.

In case of non-passing of the verification (that is to say in case of inequality in the step of comparing the above hash value with the above result), the installation process of the data processing component COMPi ends, sending an error message (possibly transmitted, for example, to the remote server S) to the processing unit 4, if applicable.

In the case where the signature sig (compound) is validated (that is to say in the case where equality occurs in the step of comparing the above hash value with the above result), the electronic device 6, 8 compares the hash value h (content) contained in the list compound with the hash value obtained by applying the hash function (in this case SHA256) to the content of the received data processing component COMPi.

In case of non-passing of the verification (that is to say in case the hash value h (content) of the list compound is not equal to the obtained hash value), the installation process of the data processing component COMPi ends, sending an error message (possibly transmitted to the remote server S, for example) to the processing unit 4, if applicable.

In the case of a pass of the verification (that is to say in the case where the hash value h (content) of the list compound is equal to the obtained hash value), the installation method continues as described here.

For example, in the case where the vehicle V is a vehicle with a heat engine, a step E38 of waiting for the heat engine to run may be provided (which makes it possible in practice to ensure that all the electronic equipment is running and that the data processing component COMPi will be able to be correctly installed in the electronic equipment in question).

When the heat engine is running (or for a vehicle without a heat engine there is no such condition), the electronic device 6, 8 in question controls the installation of the data processing component COMPi, that is to say stores the data processing component COMPi in a non-volatile (rewritable) memory for subsequent use.

In some cases (for example, for the first electronic control unit 6), the installation of the data processing component COMPi is carried out within the electronic device itself (in this case the first electronic control unit 6) which has carried out the above-mentioned verification steps E20 to E36.

In contrast, in other cases (in this example, for the gateway 8), the electronic device (in this case the gateway 8) responsible for the installation and having performed in this case the previous verification steps E20 to E36 controls the installation of the data processing component COMPi in another electronic device (in this case the second electronic control unit 10). The gateway 8 thus controls, for example, the storage of the data processing components COMPi in a non-volatile (rewritable) memory of the second electronic control unit 10.

In this case, the data processing components are not used immediately after installation, but rather when other conditions are met, as described herein.

When the vehicle V is a vehicle with a heat engine, step E42 of waiting for the stop of the operation of the heat engine may be used.

When the heat engine of vehicle V is stopped (or when vehicle V is not using the heat engine), processing unit 4 displays on a user interface (e.g., a screen disposed in the passenger compartment of vehicle V) an indication that the data processing assembly is installed and available for use (step E44).

The processing unit 4 thus waits in step E46 for a response from a user, for example the driver of the vehicle V, for example by means of the above-mentioned user interface (and where applicable the above-mentioned screen when it is a touch screen).

In the case where the user makes a negative response, the data processing component(s) installed in step E40 are not used.

In the case of a positive response by the user in step E46, the processing unit 4 transmits a command CMD for activating the installed data processing components to the various electronic devices in question (in this case to the first electronic control unit 6 and to the second electronic control unit 10 via the gateway 8) (step E48).

The installed data processing component is then activated (step E50).

For a software data processing component, the instructions comprised in the data processing component in question may then be executed by the processor of the electronic device 6, 10 in which the data processing component has been installed.

For data processing components formed by manipulatable data, the data comprised in the data processing component in question may be manipulated by the processor of the electronic device 6, 10 in which the data processing component has been installed.