Method for Installing Computing Components and Associated Electronic Devices

Abstract

1. A method for installing a computing component (COMP1) in an electronic device equipped in a vehicle, the method comprising the steps of: receiving a device packet (ECUPACKIND) including a manifest (ECUPACKIND) including a hash value (H(COMP1)) of the computing component; checking the integrity of the manifest (ECUPACKIND); receiving the computing component (COMP1); checking the correlation between the hash value (H(COMP1)) of the computing component and the received computing component (COMPi); and installing the computing component (COMP1) only in case of a positive check of the integrity of the manifest (ECUPACKIND) and a positive check of the correlation. An associated electronic device is also described.

Description

Technical Field

[0001] The present invention generally relates to the installation of data processing components into a vehicle, particularly an automobile.

[0002] The present invention is particularly advantageously used in situations where such data processing components are downloaded into a vehicle, but is also used when the data processing components are locally loaded into the vehicle, for example from a memory card.

[0003] More particularly, the present invention relates to a method for installing a data processing component and an associated electronic device.

Background Art

[0004] In some situations, it is desirable to install a data processing component in an electronic device installed in a vehicle. This is particularly true when it is desirable to update the software implemented within the electronic device or the data operated on by the electronic device.

[0005] Naturally, the installation of such a data processing component has an impact on the subsequent operation of the vehicle and must be performed in a controlled manner.

Summary of the Invention

[0006] In this context, the present invention is a method for installing a data processing component in an electronic device installed in a vehicle, the method comprising: - receiving a device packet including a first manifest containing a hash value of the data processing component; - verifying the integrity of the first manifest; - receiving the data processing component; - verifying the correspondence between the hash value of the data processing component and the received data processing component; - Install the data processing component only in the case of positive verification of the integrity of the first manifest and positive verification of the correspondence relationship and steps. A method is proposed.

[0007] Thus, as a result of the present invention, the vehicle receives a data structure that is associated with the data processing component and is involved in verifying the integrity of the data processing component (using a hash value in particular). The proposed solution further enables the separate transmission of the device packet and the data processing component itself, providing greater flexibility during the design of the vehicle and the vehicle's electronics.

[0008] It is further possible to provide the above-mentioned first manifest for including the first vehicle identifier and an installation method that further includes steps involving: - Comparing the first vehicle identifier with a second vehicle identifier stored in the vehicle - Installing the data processing component only in the case of a positive comparison between the first identifier and the second identifier.

[0009] Other advantageous and non-limiting features of the method according to the present invention are performed individually or according to all technically possible combinations and are as follows.

[0010] - The device packet includes a first signature.

[0011] - The integrity of the manifest is verified by applying a cryptographic signature verification algorithm to the first signature and the first manifest.

[0012] - The data processing component is received independently of the device packet.

[0013] - The data processing component is received within the device packet.

[0014] - The data processing component includes a second signature and content.

[0015] - The method includes the step of verifying the integrity of the content using the second signature.

[0016] The method can further include steps involving: - Receiving a container including a device packet and a second manifest - Verifying the integrity of the second manifest

[0017] Thus, this second manifest can include a first vehicle identifier, and the installation method can, in this case, include steps involving: - Comparing the first vehicle identifier with a second vehicle identifier stored in the vehicle - Transmitting the device packet only in the case of a positive comparison between the first identifier and the second identifier.

[0018] Thus, the container can include, for example, another device packet for another electronic device.

[0019] This container can be further received directly from a remote server (e.g., via a communication established between the remote server and the vehicle, which can partially use a wireless link between the vehicle and the cellular telephone network) in response to a request transmitted by the vehicle, and in one variant, the container can be received from a memory card inserted into a reader installed in the vehicle.

[0020] Finally, the present invention relates to an electronic device for providing to a vehicle, the electronic device comprising: - A module for receiving a device packet including a manifest containing a hash value of a data processing component - A module for verifying the integrity of the manifest - A module for receiving a data processing component - A module for verifying the correspondence between the hash value of a data processing component and the received data processing component - An installation module configured to install a data processing component only in the case of a positive verification of the manifest integrity and a positive verification of the correspondence

[0021] A manifest for including a first vehicle identifier can be further provided, and thus the electronic device can include a module for comparing the first vehicle identifier with a second identifier of the vehicle stored in the vehicle

[0022] The installation module may be configured to install a data processing component only in the case of a positive verification of the manifest integrity, a positive comparison between the first identifier and the second identifier, and a positive verification of the correspondence

[0023] In addition to protecting the integrity and authenticity brought about by the verification of the manifest, using the target vehicle identifier in the manifest can add protection of legality. This is because the on-board process to be updated can surely verify that the received image is not damaged, is official, and is compatible with specific hardware, but this does not necessarily imply that the vehicle can properly receive the image. In the event of a cyber-attack or malicious processing in the end-to-end transmission chain, a compatible vehicle image may be inserted instead of the source image. Therefore, the vehicle identifier in the manifest can prevent any occurrence of fraud in this scenario

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

[0025] The above-described module is executed by the cooperation of the processor and specific instructions when, for example, in this case, specific instructions configured to execute functions attributed to the module (as described below) are executed by the processor.

[0026] Of course, the various features, variations, and embodiments of the present invention may be associated with each other in various combinations, provided they are not incompatible or mutually exclusive.

[0027] The following description, made with reference to the accompanying drawings, is presented as a non-limiting example and should provide a sufficient understanding of what the present invention encompasses and how it can be implemented.

Brief Description of the Drawings

[0028]

Figure 1

Figure 2

Figure 3

Figure 4

Modes for Carrying Out the Invention

[0029] The system of FIG. 1 includes a vehicle V (e.g., an automobile), a mobile phone network N, a wide area network I (such as the Internet), and a remote server S.

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

[0031] Figure 1 shows elements of vehicle V that are advantageous for understanding the present invention. However, vehicle V will of course actually include other elements, specifically other electronic control units, i.e., processors.

[0032] The above-described electronic devices (communication unit 2, processing unit 4, first electronic control unit 6, gateway 8, and second electronic control unit 10) may each actually be manufactured 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).

[0033] The processing unit 4 itself may actually be executed using an electronic control unit having functions other than those described below, if available.

[0034] As schematically shown in Figure 1, the processing unit 4 is connected to these various electronic devices so as to be able to exchange data with the communication unit 2, the first electronic control unit 6, and the gateway 8. The communication unit 2, the processing unit 4, the electronic control unit 6, and the gateway 8 are connected to a data processing network (not shown) on the same board, for example, a CAN bus (Controller Area Network), for this purpose.

[0035] The gateway 8 is further connected to the second electronic control unit 10, for example, by a dedicated bus.

[0036] Vehicle V may further include a reader 12 for a memory card 20 that can be used in a structural variant of the present invention as described below.

[0037] The communication unit 2 is configured to perform a communication C (as schematically shown in FIG. 1 by a continuous line indicating that the connection is a physical type of connection such as 3G / 4G, Wi-Fi, etc.) within the mobile phone network N. Thus, it is possible to establish a connection with the remote server S via the mobile phone network N and the wide area network I (in particular by using the wireless link between the vehicle V and the cellular phone network which is part of the mobile phone network N), whereby the processing unit 4 and the remote server S can exchange data D (as schematically shown in FIG. 1 by a dotted line indicating that the connection is a logical type of connection), especially in the context of the installation status of the data processing components within the vehicle V as described below.

[0038] FIG. 2 shows an example of data compilation that can be used in the context of the present invention.

[0039] These data specifically include data processing components COMP1, COMP2, COMPi, and in this case, each is preferably installed in one or more electronic devices of the vehicle V, such as the first electronic control unit 6 and / or the second electronic control unit 10, each being referred to using the term "electronic device".

[0040] In this case, the data processing components COMP1, COMP2, COMPi are encapsulated within a tree structure and a branching structure as follows. - The download packet DPACK includes one or more device packets ECUPACK1, ECUPACK2, ECUPACKn, each related to an electronic device of the vehicle V. - Each device packet ECUPACK contains data regarding one or more data processing components COMP1, COMP2, COMPi for a specific electronic device.

[0041] This Russian doll - type encapsulation method is particularly advantageous because, in addition to being able to separate the content for each target component, i.e., in this specification, for each of the electronic control units 2, 4, 6, 8, and 10 whose software can be remotely updated (or firmware over - the - air (FOTA)), it is also possible to ensure the consistency of updates within the same electronic component. Furthermore, this encapsulation enables the achievement of a level of verification of integrity / authenticity that includes several stages. More specifically, the communication unit 2 can perform a first - level verification on the download packet DPACK. As soon as it is proven that this verification is correct, the device packet ECUPACK is extracted and distributed to the target components 2, 4, 6, 8, and 10. Thus, the target components 2, 4, 6, 8, and 10 can perform a level - 2 verification using various cryptographic hardware, and the level - 2 verification enables the separation of content for each component to be generated (there can be many providers of components). After the device packet ECUPACK is authenticated, the data - processing components COMP1, COMP2, COMPi are extracted and then proven correct at a third cryptographic level and, in the case of a positive verification, may ultimately be installed. Thus, this process enables the method to perform verification in two levels (the download packet DPACK is verified in a non - trusted connection zone, the device packet ECUPACK is extracted and shared with the trusted zone, and its verification is to be performed in the trusted zone) for the communication unit 2, which often consists of a secure zone or protected zone (i.e., a trusted zone) and a non - secure zone (i.e., a non - trusted zone), so it is particularly advantageous in the case where the target processor is the communication unit 2. In this way, ultimately, whether the target ECU is local or remote (to other ECUs in the vehicle network), the method enables verification at several levels.In another approach, further shown in Figure 2 where component COMP is not within device packet ECUPACK, component COMP will be received in a secondary exchange process and proven correct by hash values H(COMP1), H(COMP2), H(COMPi) stored in a first instance within device packet ECUPACK. Encapsulating update content within a component enables the control of the constructor-level electronic signature to ensure image authentication in order to guarantee the control of introduction. This signature operation of the component will be performed, for example manually, by an approved security agent (with specific privileges) on the premises of the vehicle manufacturer. Without this operation, it is not possible to introduce non-corrupted content into the vehicle. This signature level can be, for example, manual (especially ASSIM signing) and can control the authorization of introduction. In this way, without this verification level that can guarantee to processors 2, 4, 6, 8, or 10 that only formally binary update content provided by the supplier and not corrupted can be transmitted to the vehicle, which is certified by the vehicle manufacturer, it would be impossible for processors 2, 4, 6, 8, or 10 to utilize it. This further enables the quality of the target software to be guaranteed before introduction.

[0042] As described below, each of these packets contains a digital signature used for the installation of data processing components. As envisioned below, the verification of digital signatures requires a specific cryptographic infrastructure as described herein.

[0043] To simplify the presentation, any digital signature is simply referred to below as "signature".

[0044] The following are used specifically below: - Root certificate ROOT.cert containing metadata ROOT.md and public key ROOT.Kpub associated with private key ROOT.Kpriv - The certificate CA.cert of the authority that holds the metadata CA.md, the public key CA.Kpub, and the signature CA.sig - The certificate R.cert of the manufacturer that holds the metadata R.md, the public key R.Kpub, and the signature R.sig - The public key BK.Kpub associated with the private key BK.Kpriv.

[0045] The private key CA.Kpriv is associated with the public key CA.Kpub.

[0046] Similarly, the private key R.Kpriv is associated with the public key R.Kpub.

[0047] In this case, the terms, associated public and private keys are intended to be understood as referring to the associated public and private keys in a "public key infrastructure" (i.e., PKI).

[0048] In such a context, a group of data may be signed by applying an (in this case RSA type) cryptographic signature algorithm that uses a private key to this group of data, and then the signature can be verified using an associated (in this case also RSA type) cryptographic signature verification algorithm that uses the public key associated with the above-mentioned private key.

[0049] The signature CA.sig of the authority's certificate CA.cert is obtained by applying a cryptographic signature algorithm that uses 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 certification authority).

[0050] The signature R.sig of the manufacturer's certificate R.cert itself is obtained by applying a cryptographic signature algorithm that uses 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 above-mentioned certification authority).

[0051] The various data structures shown in FIG. 2 are described in detail here.

[0052] Each data processing component COMP to be installed includes the following: - CONTENT CONTEN containing data to be installed (actually to be stored) in the corresponding electronic device - In particular, the hash value H(CONTEN) of the content to be installed, and if available, a manifest COMPIND containing a description of the data processing component, such as a description of the functions updated by this component - The signature SIG(COMPIND) of the manifest COMPIND.

[0053] These data to be installed can constitute software or a part of software (e.g., software updates). Therefore, this software or a part of software is configured to be at least partially executed by the processor of the corresponding electronic device. In one variant, these data to be installed may be data (e.g., map data) to be stored for subsequent operations by the processor of the corresponding electronic device.

[0054] The hash value H(CONTEN) is obtained by applying a hash value function (e.g., of type SHA-256) to the content CONTEN.

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

[0056] For example, these operations are executed by a certification authority of the corresponding (e.g., software) content CONTEN.

[0057] In this case, each device packet ECUPACK includes the following: - One or more data processing components COMP1, COMP2, COMPi as described above - Hash values H(COMP1), H(COMP2), H(COMPi) for each of the data processing components COMP1, COMP2, COMPi contained in the device packet ECUPACK, and if available, a vehicle identifier VIN, and / or a manifest ECUPACKIND including what describes the data processing components COMP1, COMP2, COMPi contained in the packet - A signature SIG(ECUPACKIND) of the manifest ECUPACKIND.

[0058] Several variants may be implemented to provide the identifier VIN. By including the identifier VIN in the device packet ECUPACK as described above, the device packet ECUPACK can guarantee that the data processing components installed in an electronic device (e.g., a vehicle's processor) truly belong to this vehicle. This is because one component may become very suitable for many vehicles of the same type, for example, providing the user with the possibility of replacing the processor of their vehicle with a processor of another vehicle of the same type. By including the VIN identifier in the device packet ECUPACK, this operation can be avoided.

[0059] In one variant, it is still possible to authorize this operation, for example, by putting the vehicle identifier VIN in the manifest DPACKIND as described below, as in the case of the variant shown in Figure 3. In this case, it is possible to assume that the device packet ECUPACK is transmitted to the corresponding electronic device (using the processing unit 4) only in the case of a positive comparison between the identifier VIN received in the manifest DPACKIND and the identifier of vehicle V as stored (in the processing unit 4 in this case).

[0060] According to other possible embodiments, the identifier VIN may be included in both the manifest DPACKIND and the manifest ECUPACKIND for a data processing component that is compatible with any particular vehicle, such as a data processing component that includes map data of a navigation system, for example, or may not be included in either of these two manifests.

[0061] In this case, the identifier VIN of the vehicle V is a number uniquely associated with the vehicle and is generally called the VIN "Vehicle Identification Number".

[0062] The hash values H(COMP1), H(COMP2), H(COMPi) are obtained by applying a hash function (e.g., of type SHA-256) to the data constituting the respective data processing components COMP1, COMP2, COMPi, for example, in the definition of the device packet ECUPACK (depending on the requirements of the device, particularly the update requirements of this device).

[0063] The signature SIG(ECUPACKIND) is obtained by applying a cryptographic signature algorithm using the private key R.Kpriv (associated with the manufacturer's certificate R.cert) to the manifest ECUPACKIND.

[0064] For example, these operations are performed by the vehicle manufacturer (or on behalf of the vehicle manufacturer) when the data processing component to be installed is defined for the particular electronic device in a particular vehicle (identified using the identifier VIN).

[0065] In practice, for example, the signature SIG(ECUPACKIND) is stored in a dedicated field of the device packet ECUPACK, such as in a field within, for example, the cms format (Cryptographic Message Syntax). In this case, this field can include the signature SIG(ECUPACKIND), the authority's certificate CA.cert, and the manufacturer's certificate R.cert.

[0066] The download packet DPACK includes the following: - One or more device packets ECUPACK1, ECUPACK2, ECUPACKn as described above - Hash values H(ECUPACK1), H(ECUPACK2), H(ECUPACKn) for each of the device packets ECUPACK1, ECUPACK2, ECUPACKn specifically contained in the download packet DPACK, and, if available, a manifest DPACKIND including, for example, (along with an indication for each of the device packets ECUPACK1, ECUPACK2, ECUPACKn of the target electronic device for the respective device packet) a description of the device packets ECUPACK1, ECUPACK2, ECUPACKn contained in the download packet DPACK - The signature SIG(DPACKIND) of the manifest DPACKIND.

[0067] The hash values H(ECUPACK1), H(ECUPACK2), H(ECUPACKn) are obtained, for example, by applying a hash function (such as of type SHA-256) to the respective device packets ECUPACK1, ECUPACK2, ECUPACKn during the definition of the download packet DPACK (after the definition of the target electronic device and the definition of the respective requirements for each device).

[0068] The signature SIG(DPACKIND) is obtained by applying an encryption signature algorithm that uses the private key R.Kpriv (associated with the manufacturer's certificate R.cert) to the manifest DPACKIND.

[0069] For example, these operations are performed by (or on behalf of) the vehicle manufacturer when the electronic devices in question, and the data processing components that are to be installed on these electronic devices, are defined.

[0070] In practice, for example, the signature SIG(DPACKIND) is stored in a dedicated field of the download packet DPACK, such as a field within the cms format ("Cryptographic Message Syntax"). In this case, this field can contain the signature SIG(DPACKIND), the authority's certificate CA.cert, and the manufacturer's certificate R.cert.

[0071] Note that in the architecture described above, each of the data processing components COMP1, COMP2, COMPi is independent of the vehicle V to which it is to be installed (and can be used, for example, for the entire vehicle). Nevertheless, the device packets ECUPACK1, ECUPACK2, ECUPACKn (and necessarily the download packet DPACK) are specifically configured for the vehicle V.

[0072] Figure 3 includes variant forms that can be envisioned for the organization of the data within the download packet DPACK.

[0073] As already shown, in this variant form, the vehicle identifier VIN is placed within the manifest DPACKIND.

[0074] Furthermore, data processing components COMP1, COMP2, COMPi related to a specific electronic device are not included in the device packet ECUPACK1 for this electronic device. Instead, they are external to the electronic device so that, if available, they can be transmitted separately from the device packet ECUPACK1 as described below.

[0075] In this case, the device packet ECUPACK1 includes the following: - A manifest ECUPACKIND including hash values H(COMP1), H(COMP2), H(COMPi) for each of the data processing components COMP1, COMP2, COMPi associated with the electronic device - A signature SIG(ECUPACKIND) of the manifest ECUPACKIND.

[0076] An example of a method for installing a data processing component in a vehicle V according to the present invention is described here with reference to FIG. 4.

[0077] This method starts at step E2. During step E2, the processing unit 4 transmits a request REQ to the remote server S. By this request, the vehicle V attempts to determine whether a data processing component is available for installation in the vehicle V, for example, to update a specific software component or specific data (such as map data).

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

[0079] The request REQ can include the vehicle identification number VIN of the vehicle V.

[0080] 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 download for the vehicle V.

[0081] In this case, it is assumed that the data processing component is available for download and installation in the vehicle V. Inevitably, the server S transmits the global container GLOB to the processing unit 4 in step E6.

[0082] This global container GLOB includes the manifest DPACKIND, the associated signature SIG(DPACKIND), and the device packets ECUPACK1, ECUPACK2, ECUPACKn. Inevitably, according to the embodiment, this global container GLOB may or may not include the data processing components COMP1, COMP2, COMPi.

[0083] This is because, according to the first embodiment, all or part of the data processing components COMP1, COMP2, COMPi can also be transmitted in this step E6 (therefore, these components transmitted in step E6 are not transmitted in step E26 described below). Therefore, these data processing components may be transmitted within the device packet ECUPACK (e.g., within the framework of the data structure shown in FIG. 2), or together with the corresponding device packet ECUPACK1 (e.g., within the framework of the data structure shown in FIG. 3).

[0084] According to the second embodiment, the global container GLOB transmitted in step E6 does not contain any of the data processing components COMP1, COMP2, COMPi (therefore, these data processing components are transmitted during one or more steps according to step E26 described below).

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

[0086] In one variant, as shown above, in step E8, the global container GLOB can be received (regardless of the presence of data processing components) from the memory card 20 inserted into the reader 12 (and thus connected to the processing unit 4). Steps E2 to E6 are not executed in this case.

[0087] Note 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 memory size required in the processing unit 4 to store the received global container GLOB can be reduced. In other words, it is not necessary to provide a buffer memory in the processing unit 4 suitable for storing all of the download packet DPACK.

[0088] Thus, in step E10, the processing unit 4 performs verification of the manufacturer's certificate R.cert that contains the public key R.Kpub that will be used later, in particular for signature verification.

[0089] As shown above, in this case, the certificate R.cert is contained within the field in cms format of the download packet DPACK (and thus of the global container GLOB received in step E8).

[0090] To verify the manufacturer's certificate R.cert, a cryptographic signature verification algorithm that uses 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 in the CMS format as described above.) In practice, for example, the hash value of the signed data is compared with the result obtained by applying a cryptographic algorithm (in this case, of the RSA type) using the public key CA.Kpub to the signature R.sig.

[0091] If the verification fails (i.e., if they are not equal in the step of comparing the above-mentioned hash value and the above-mentioned result), the installation process is terminated, and an error message is sent to the remote server S if available.

[0092] In the case of a positive verification in step E10 (i.e., if they are equal in the step of comparing the above-mentioned hash value and the above-mentioned result), the processing unit can verify whether the certificate R.cert has expired by comparing the included date and time with the expiration date and time described in the metadata R.md.

[0093] If the certificate has expired, the installation process is terminated, and an error message is sent to the remote server S if available.

[0094] If the certificate is valid, in step E12, the processing unit 4 performs the verification of the certificate CA.cert of the authority (specifically containing the public key CA.Kpub used as described above).

[0095] As shown above, the certificate CA.cert is contained in the field in the cms format of the download packet DPACK (and thus of the global container GLOB received in step E8) in this case.

[0096] To verify the authority's 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 (in this case, of the RSA type) using the public key ROOT.KPub to the signature CA.sig.

[0097] For example, the public key ROOT.Kpub is stored in the non-volatile memory of the processing unit 4 (during the manufacture of the processing unit 4).

[0098] If verification fails (i.e., if they are not equal in the step of comparing the above hash value and the above result), the installation process is terminated and, if available, an error message is sent to the remote server S.

[0099] In the case of a positive verification in step E12 (i.e., if they are equal in the step of comparing the above hash value and the above result), the processing unit can verify whether the certificate CA.cert has expired by comparing the date and time when it was included with the date and time of the expiration date described in the metadata CA.md.

[0100] If the certificate has expired, the installation process is terminated and, if available, an error message is sent to the remote server S.

[0101] If the certificate is valid, the validity of the root certificate ROOT.cert can be similarly verified by comparing the date and time of a given time with the date and time of the expiration date of the root certificate ROOT.cert described in the metadata ROOT.md.

[0102] If the certificate has expired, the installation process is terminated and, if available, an error message is sent to the remote server S.

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

[0104] In step E14, the processing unit particularly verifies the integrity of the manifest DPACKIND (received within the global container GLOB).

[0105] For this purpose, 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 (in this case, of the RSA type) using the public key R.Kpub to the signature SIG(DPACKIND). Note that in step E10, the validity of the certificate R.cert containing the public key R.Kpub was verified.

[0106] If verification fails (i.e., if they are not equal in the step of comparing the above-mentioned hash value and the above-mentioned result), the installation process is terminated and, if available, an error message is sent to the remote server S.

[0107] In the case of a positive verification in step E14 (i.e., if they are equal in the step of comparing the above-mentioned hash value and the above-mentioned result), the installation process continues in step E16, which is described here.

[0108] In step E16, the processing unit 4 distributes various device packets ECUPACK to the electronic devices (in this case, for example, the first electronic control unit 6 and / or the gateway 8) responsible for installing the data processing components.

[0109] Depending on the corresponding embodiment, each device packet ECUPACK stores the data of the global container GLOB for a specific electronic device (in this case, the first electronic control unit 6 or the gateway 8), regardless of the presence or absence of the data processing components COMP1, COMP2, COMPi themselves, that is, the data of the device packet ECUPACKn for this electronic device.

[0110] As already shown, in fact, in step E6, all or part of the electronic components that will be transmitted in the global container GLOB, and thus at least some of the device packets ECUPACK that will include one or more data processing components, can be provided.

[0111] Therefore, each such electronic device receives the device packet ECUPACK in step E18. Although the implementation form of the method for such an electronic device (in this case, the first electronic control unit 6 or the gateway 8) is described below, similar steps are actually executed for other electronic devices that receive the device packet ECUPACK.

[0112] Therefore, if available, the electronic device (in this case, the first electronic control unit 6 or the gateway 8) can execute the step of verifying the manufacturer's certificate R.cert and the authority's certificate CA.cert in step E20. Note 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 packet ECUPACK.

[0113] The verification in step E20 (performed by the electronic devices 6, 8) 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.

[0114] If verification cannot be performed in step E20, the installation process in the devices 6, 8 is terminated. Furthermore, an error message can be sent to the processing unit 4 (for example, for the possibility of transmission to the remote server S).

[0115] In the case of positive verification in step E20, the electronic devices 6, 8 perform, in step E22, verification of the integrity of the manifest ECUPACKIND (received within the device packet ECUPACKIND).

[0116] For this purpose, the electronic devices 6, 8 apply a cryptographic signature verification algorithm using the public key R.Kpub to the signature SIG(ECUPACKIND) and the manifest ECUPACKIND. In practice, for example, the hash value of the manifest ECUPACKIND is compared with the result obtained by applying a cryptographic algorithm (in this case of the RSA type) using the public key R.Kpub to the signature SIG(ECUPACKIND). (Note that the validity of the certificate R.cert containing the public key R.Kpub was verified during step E20.)

[0117] If verification fails (i.e., if they are not equal in the step of comparing the above-mentioned hash value and the above-mentioned result), the installation process in the electronic devices 6, 8 is terminated and, if available, an error message is sent to the processing unit 4 (for example, for the possibility of transmission to the remote server S).

[0118] In the case of positive verification in step E22 (i.e., if they are equal in the step of comparing the above-mentioned hash value and the above-mentioned result), the electronic devices 6, 8 verify, in step E24, whether the vehicle V identifier VIN included in the manifest ECUPACKIND corresponds to (i.e., is actually equal to) the vehicle V identifier VIN stored in the electronic devices 6, 8 (for example, in a non-volatile memory).

[0119] If verification fails (i.e., if the identifier VIN shown in the manifest ECUPACKIND is not equal to the stored identifier), the installation process in the electronic devices 6, 8 is terminated, and if available, an error message is sent to the processing unit 4 (e.g., for the possibility of transmission to the remote server S).

[0120] In the case of a positive verification in step E24 (i.e., if the identifier VIN shown in the manifest ECUPACKIND is equal to the stored identifier), the installation can continue in step E32 as described below (after receiving the data processing component as described here).

[0121] Simultaneously with the mentioned processing in the electronic devices 6, 8 responsible for the installation, the remote server S transmits at least one data processing component COMPi of the download packet DPACK to the processing unit 4 in step E26. (Although this is not shown in FIG. 4, this transmission of the data processing component COMPi may be started after an instruction from the processing unit 4 is received by the remote server S. For example, this instruction indicates that there is sufficient space in the buffer memory for storing the data processing component COMPi.)

[0122] The processing unit 4 receives the data processing component COMPi in step E28.

[0123] The processing of one data processing component COMPi is described here below. In fact, several data processing components are received simultaneously or later depending on the capacity of the buffer memory of the processing unit 4 and are processed as described for the data processing component COMPi.

[0124] When the component COMPI received in step E28 enables the processing unit 4 to supplement the device packet ECUPACKn (using the data of the global container GLOB), if available, in step E29, for example, the processing unit 4 compares the hash value H(ECUPACKn) stored in the manifest DPACKIND with the hash value obtained by applying a hash function (SHA256 in this case) to the received device packet ECUPACKn, thereby verifying the content of the said device packet ECUPACKn.

[0125] If verification fails (i.e., the hash value H(ECUPACKn) in the manifest DPACKIND is different from the hash value obtained based on the received device packet ECUPACKn), the data processing component COMPi is not communicated to the said electronic devices 6, 8, and if available, an error message can be sent to the remote server S.

[0126] In the case of a positive verification in step E29, i.e., the hash value H(ECUPACKn) in the manifest DPACKIND is equal to the hash value obtained based on the received device packet ECUPACKn, the data processing component COMPi is distributed to the said electronic devices 6, 8 in step E30.

[0127] Therefore, the said electronic devices 6, 8 receive the data processing component COMPi in step E32.

[0128] Therefore, the electronic devices 6, 8 can verify this data processing component COMPi.

[0129] First, in step E34, the electronic devices 6 and 8 compare the hash value H(COMPi) stored in the manifest ECUPACKIND with the hash value obtained by applying a hash function (SHA256 in this case) to the received data processing component COMPi. (Note that the integrity of the manifest ECUPACKIND was verified in step E22.)

[0130] In the case of a negative verification (i.e., when the hash value H(COMPi) stored in the manifest ECUPACKIND is different from the obtained hash value), the installation of the data processing component COMPi is terminated.

[0131] In the case of a positive verification in step E34 (i.e., when the hash value H(COMPi) stored in the manifest ECUPACKIND is equal to the obtained hash value), the verification of the data processing component COMPi continues in step E36.

[0132] First, in step E36, the electronic devices 6 and 8 verify the integrity of the manifest COMPIND of the data processing component COMPi.

[0133] For this purpose, the electronic devices 6 and 8 apply a cryptographic signature verification algorithm using the public key BK.Kpub to the signature SIG(COMPIND) and the manifest COMPIND. In practice, the hash value of the manifest COMPIND and the result obtained by applying the signature SIG(COMPIND) of a cryptographic algorithm (RSA type in this case) are compared, for example, using the public key BK.KPub.

[0134] For example, the public key BK.Kpub is stored in the non-volatile memory of the electronic devices 6 and 8.

[0135] If verification fails (i.e., if they are not equal in the step of comparing the above-mentioned hash value with the above-mentioned result), the installation process of the data processing component COMPi is terminated, and if available, an error message is sent to the processing unit 4 (e.g., for the possibility of transmission to the remote server S).

[0136] In the case of a positive verification of the signature SIG(COMPIND) (i.e., if they are equal in the step of comparing the above-mentioned hash value with the above-mentioned result), the electronic devices 6, 8 compare the hash value H(CONTEN) stored in the manifest COMPIND with the hash value obtained by applying a hash function (in this case SHA256) to the content CONTEN of the received data processing component COMPi.

[0137] If verification fails (i.e., if the hash value H(CONTEN) of the manifest COMPIND and the obtained hash value are not equal), the installation process of the data processing component COMPi is terminated, and if available, an error message is sent to the processing unit 4 (e.g., for the possibility of transmission to the remote server S).

[0138] In the case of a positive verification (i.e., if the hash value H(CONTEN) of the manifest COMPIND and the obtained hash value are equal), the installation method continues as described here.

[0139] For example, in the case where the vehicle V is a vehicle having a heat engine, accordingly, the step E38 of waiting for the operation of the heat engine can be performed (by this step, it can be actually guaranteed to the heat engine that all the electronic devices are operating and the data processing component COMPi can be correctly installed in the corresponding electronic device).

[0140] When the heat engine is operable (or there is no such condition for a vehicle without a heat engine), the electronic devices 6, 8 control the installation of the data processing component COMPi, that is, the storage of the data processing component COMPi in a non-volatile (rewritable) memory, with a view to its subsequent use.

[0141] 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) that has executed the previous verification steps E20 to E36 described above.

[0142] In contrast, in other cases (in this case, for the gateway 8), the electronic device (in this case, the gateway 8) that is responsible for the installation and has executed the previous verification steps E20 to E36 in this context controls the installation of the data processing component COMPi in another electronic device, in this case, within the second electronic control unit 10. Thus, the gateway 8 controls, for example, the storage of the data processing component COMPi in the non-volatile (rewritable) memory of the second electronic control unit 10.

[0143] In this case, as described here, although it is not intended to be used immediately after installation, it provides data processing components when following other conditions.

[0144] When the vehicle V is a vehicle with a heat engine, the step E42 of waiting for the operation of the heat engine to stop can be used.

[0145] When the heat engine of the vehicle V stops (or when the vehicle V does not use a heat engine), the processing unit 4 displays an instruction on the user interface (for example, a screen arranged in the passenger compartment of the vehicle V) that the data processing component has been installed and is ready for use (step E44).

[0146] Therefore, in step E46, the processing unit 4 waits for a response from the user (e.g., the driver of the vehicle V) via, for example, the above-mentioned user interface (if available, the above-mentioned screen if this screen is a touch screen).

[0147] In the case of a negative response from the user, the data processing component installed in step E40 is not used.

[0148] In the case of an affirmative response from the user in step E46, the processing unit 4 transmits a command CMD for activating the data processing component installed in the various electronic devices (in this case, to the first electronic control unit 6 and, via the gateway 8, to the second electronic control unit 10) (step E48).

[0149] Next, the installed data processing component is activated (step E50).

[0150] For the software data processing component, next, the instructions included in the data processing component may be executed by the processors of the electronic devices 6, 10 in which the data processing component is installed.

[0151] For the data processing component formed from actionable data, the data included in the data processing component may be operated on by the processors of the electronic devices 6, 10 in which the data processing component is installed.

Claims

1. A method performed by a computer for installing a data processing component (COMP1) in an electronic device (6, 10) provided in a vehicle (V), comprising: - receiving a device packet (ECUPACK) including a first manifest (ECUPACKIND) including a hash value (H(COMP1)) of the data processing component (E18); - verifying the integrity of the first manifest (ECUPACKIND) (E22); - receiving the data processing component (COMP1) (E32); - verifying the correspondence between the hash value (H(COMP1)) of the data processing component and the received data processing component (COMP1) (E34); - installing the data processing component (CCOMP1) only in the case of a positive verification of the integrity of the first manifest (ECUPACKIND) and a positive verification of the correspondence (E40); steps including including wherein the method further includes - receiving a container (GLOB) including the device packet (ECUPACK) and a second manifest (DPACKIND) (E8); - verifying the integrity of the second manifest (DPACKIND) (E14). A method further including steps.

2. A method performed by a computer for installing a data processing component (COMP1) in an electronic device (6, 10) provided in a vehicle (V), comprising: - receiving a device packet (ECUPACK) including a first manifest (ECUPACKIND) including a hash value (H(COMP1)) of the data processing component (E18); - verifying the integrity of the first manifest (ECUPACKIND) (E22); - receiving the data processing component (COMP1) (E32); - verifying the correspondence between the hash value (H(COMP1)) of the data processing component and the received data processing component (COMP1) (E34); - Installing the data processing component (CCOMP1) (E40) only in the case of a positive verification of the integrity of the first manifest (ECUPACKIND) and a positive verification of the correspondence relationship including steps accompanied by The data processing component (COMP1) includes a second signature (SIG(COMPIND)) and content (CONTEN), and the method further includes a step (E36) of verifying the integrity of the content (CONTEN) using the second signature (SIG(COMPIND)). **Claim 3** The first manifest (ECUPACKIND) includes a first vehicle identifier (VIN), and the method - Comparing the first vehicle identifier (VIN) with a second vehicle identifier stored in the vehicle (V) (E24); - Installing the data processing component (COMP1) (E40) only in the case of a positive comparison between the first vehicle identifier (VIN) and the second vehicle identifier The method according to claim 1 or 2, including steps accompanied by **Claim 4** The device packet (ECUPACK) includes a first signature (SIG(ECUPACKIND)), and the integrity of the manifest (ECUPACKIND) is verified by applying a cryptographic signature verification algorithm to the first signature (SIG(ECUPACKIND)) and the first manifest (ECUPACKIND). The method according to any one of claims 1 to 3. **Claim 5** The method according to any one of claims 1 to 4, wherein the data processing component (COMP1) is received independently of the device packet (ECUPACK). **Claim 6** The method according to any one of claims 1 to 4, wherein the data processing component (COMP1) is received within the device packet (ECUPACK). **Claim 7** The method according to claim 1, wherein the container (GLOB) includes another device packet (ECUPACK2) for another electronic device. **Claim 8** The second manifest (DPACKIND) includes a first vehicle identifier (VIN), and the method - Comparing the first vehicle identifier (VIN) with a second vehicle identifier stored in the vehicle (V) (E12); - Transmitting the device packet (ECUPACK) only in the case of a positive comparison between the first vehicle identifier (VIN) and the second vehicle identifier (E16); The method according to claim 1 or 7, comprising steps involving this. **Claim 9** The method according to any one of claims 1, 7 or 8, wherein the container (GLOB) is received from a remote server (S) in response to a request (REQ) transmitted by the vehicle (V). **Claim 10** The method according to any one of claims 1, 7 or 8, wherein the container (GLOB) is received from a memory card (20) inserted into a reader (12) installed in the vehicle (V). **Claim 11** An electronic device (6, 8) for providing to a vehicle, comprising: - A module for receiving a device packet (ECUPACK) containing a manifest (ECUPACKIND) including a hash value (H(COMPi)) of a data processing component; - A module for verifying the integrity of the manifest (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 in the case of a positive verification of the integrity of the manifest (ECUPACKIND) and a positive verification of the correspondence; Comprising: The electronic device (6, 8) further comprising: - A module for receiving a container (GLOB) containing the device packet (ECUPACK) and a second manifest (D PACKIND); - A module for verifying the integrity of the second manifest (D PACKIND). The electronic device (6, 8). **Claim 12** An electronic device (6, 8) for providing to a vehicle, comprising: - A module for receiving a device packet (ECUPACK) containing a manifest (ECUPACKIND) including a hash value (H(COMPi)) of a data processing component; - A module for verifying the integrity of the manifest (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 in the case of a positive verification of the integrity of the manifest (ECUPACKIND) and a positive verification of the correspondence; comprising; The data processing component (COMP1) includes a second signature (SIG(COMPIND)) and content (CONTEN), and the electronic device (6, 8) further comprises a module for verifying the integrity of the content (CONTEN) using the second signature (SIG(COMPIND)). An electronic device (6, 8). [

13. ] The manifest (ECUPACKIND) includes a first vehicle identifier (VIN), and the electronic device - A module for comparing the first vehicle identifier (VIN) with a second vehicle identifier of the vehicle (V) stored in the vehicle (V); comprising; The installation module is configured to install the data processing component (COMPi) only in the case of a positive verification of the integrity of the manifest (ECUPACKIND), a positive comparison between the first vehicle identifier (VIN) and the second vehicle identifier, and a positive verification of the correspondence. The electronic device (6, 8) according to claim 11 or 12.

Images