EP3970315A1 - Procede d'installation d'un composant informatique et equipement electronique associe - Google Patents

Procede d'installation d'un composant informatique et equipement electronique associe

Info

Publication number
EP3970315A1
EP3970315A1 EP20717217.2A EP20717217A EP3970315A1 EP 3970315 A1 EP3970315 A1 EP 3970315A1 EP 20717217 A EP20717217 A EP 20717217A EP 3970315 A1 EP3970315 A1 EP 3970315A1
Authority
EP
European Patent Office
Prior art keywords
vehicle
computer component
ecupackind
manifest
identifier
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP20717217.2A
Other languages
German (de)
English (en)
Inventor
Eric Abadie
Sébastien BESSIERE
Pascal Menier
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ampere SAS
Nissan Motor Co Ltd
Original Assignee
Renault SAS
Nissan Motor Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Renault SAS, Nissan Motor Co Ltd filed Critical Renault SAS
Publication of EP3970315A1 publication Critical patent/EP3970315A1/fr
Pending legal-status Critical Current

Links

Classifications

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

Definitions

  • the present invention relates generally to the installation of computer components in vehicles, in particular motor vehicles.
  • the present invention proposes a method for installing a computer component in electronic equipment fitted to a vehicle, comprising the steps of:
  • the vehicle receives a data structure associated with the computer component and participating (in particular by means of the condensate) in verifying the integrity of the computer component.
  • the proposed solution further makes possible the separate transmission of the equipment package and the computer component itself, which gives more flexibility in the design of the vehicle and its electronic equipment.
  • the equipment package includes a first signature
  • the computer component comprises a second signature and a content
  • the method comprises a step of verifying the integrity of the content by means of the second signature.
  • the method can also comprise steps consisting in:
  • This second manifesto can then include a first identifier of vehicle and the installation method may in this case include steps consisting of:
  • the container can then for example comprise another package of equipment intended for other electronic equipment.
  • This container can also be received from a remote server (for example directly via a communication established between the remote server and the vehicle, this communication being able in part to use a radio link between the vehicle and a cellular network of telephony) in response to a request from the vehicle; alternatively, the container can be received from a memory card inserted into a reader fitted to the vehicle.
  • a remote server for example directly via a communication established between the remote server and the vehicle, this communication being able in part to use a radio link between the vehicle and a cellular network of telephony
  • the invention relates to electronic equipment intended to equip a vehicle and comprising:
  • a module for receiving an equipment package comprising a manifesto including a digest of a computer component
  • an installation module designed to install the IT component only in the event of a positive verification of the integrity of the manifest and a positive verification of the correspondence.
  • the installation module can be designed to install the computer component only if there is a positive verification of the integrity of the manifest, a positive comparison of the first identifier and the second identifier, and a positive verification of the correspondence.
  • the use of the identifier of the vehicle targeted in the latter makes it possible to add protection of legitimacy.
  • the on-board update process can certainly verify that a received image is intact, authentic and compatible on a given piece of equipment, but this does not necessarily imply that said vehicle is legitimate to receive it.
  • an image of a compatible vehicle could be inserted instead of the source image. The vehicle identifier in the manifesto will therefore not be deceived during this scenario.
  • Such electronic equipment is, for example, an electronic control unit (or computer) comprising a processor and a memory storing computer program instructions that can be executed by the processor.
  • modules are for example implemented here by the cooperation of the processor and certain instructions designed to implement the functionality assigned to the module concerned (as described below) when these instructions are executed by the processor.
  • Figure 1 schematically shows a system in which the invention can be implemented
  • FIG. 2 represents an example of an organization of data that can be used within the framework of the invention
  • FIG. 3 shows another example of a data organization that can be used within the framework of the invention.
  • Figure 4 shows an example of a method of installing computer components in a vehicle according to the invention.
  • the system of Figure 1 comprises a vehicle V (for example a vehicle automobile), a mobile telephone network N, a wide area network I (such as the Internet network) and a remote server S.
  • vehicle V for example a vehicle automobile
  • mobile telephone network N for example a mobile telephone network
  • wide area network I such as the Internet network
  • remote server S for example a remote server
  • the vehicle V comprises 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 There is shown in Figure 1 the elements of the vehicle V useful for understanding the invention, but the vehicle V naturally includes other elements in practice, in particular other electronic control units or computers.
  • each of these electronic items of equipment comprises a processor and at least one memory (for example a random access memory and / or a non-volatile memory).
  • the processing unit 4 can itself be implemented in practice by means of an electronic control unit, possibly having other functions than those described below.
  • the processing unit 4 is connected to the communication unit 2, to the first electronic control unit 6 and to the gateway 8 in order to be able to exchange data with these various electronic devices.
  • the communication unit 2, the processing unit 4, the electronic control unit 6 and the gateway 8 are for example connected to this (same) on-board computer network (not shown), for example a CAN bus (for "Controller Area Network).
  • the gateway 8 is also connected to the second electronic control unit 10, for example by means of a dedicated bus.
  • the vehicle V can further include a reader 12 of a memory card 20, usable in an alternative embodiment of the invention, as mentioned below.
  • the communication unit 2 is designed to implement a C communication (as shown schematically in Figure 1 by a solid line which means that this connection is of physical type, for example 3G / 4G, WiFi or other) in the mobile telephone network N and can thus establish a connection with the remote server S via the mobile telephone network N (in particular by using a radio link between the vehicle V and a cellular telephone network forming part of the mobile telephone network N) and the wide area network I, so that the processing unit 4 and the remote server S can exchange data D (as shown diagrammatically in FIG. 1 by a dotted line which means that this connection is of logical type), in particular in the context of the installation of computer components within the vehicle V, as described below.
  • a C communication as shown schematically in Figure 1 by a solid line which means that this connection is of physical type, for example 3G / 4G, WiFi or other
  • Figure 2 shows an example of data organization, usable in the context of the invention.
  • COMP1, COMP2, COMPi are here encapsulated within a tree structure as follows:
  • a DPACK download package includes one or more equipment package (s) ECUPACK1, ECUPACK2, ECUPACKn relating (each) to electronic equipment of the vehicle V;
  • each ECUPACK equipment package includes data relating to one or more computer component (s) COMP1, COMP2, COMPi intended for a particular electronic equipment.
  • This Russian doll type encapsulation method is particularly advantageous because beyond the fact that it allows content segregation by target part, that is to say here by electronic control unit 2,4, 6, 8 and 10, the software of which can be modified by remote update (or firmware over the air in English, FOTA), it also makes it possible to guarantee updating consistency within the same electronic part.
  • this encapsulation makes it possible to have several stages of integrity / authenticity verification levels. More precisely, the communication unit 2 will be able to carry out a 1st level check on the DPACK download packet and once this check is validated the packet (s) ECUPACK equipment will be extracted and distributed to target coins 2, 4, 6, 8 and 10.
  • Target coins 2, 4, 6, 8 and 10 will then be able to perform a level 2 verification, with different cryptographic material, allowing to create a content isolation by part (of which the suppliers can be multiple).
  • the computer components COMP1, COMP2, COMPi can be extracted, validated in turn by a 3rd cryptographic level and be finally installed in the event of positive verification.
  • the target computer is the communication unit 2, because for the latter, which is often composed of a secure or protected zone (or trusted zone in English) and of an unsecured zone (or untrusted zone in English), the process then makes it possible, like a remote computer, to perform a 2-level verification: the DPACK download packet is verified in the unsecured connected zone, the ECUPACK equipment packet is extracted and shared at the secure area, and verification of the latter will be done in secure area.
  • the target ECU is local or remote (another ECU in the vehicle network)
  • the method allows verification at several levels.
  • This level of signature is for example manual (in particular ASSIM signing), and makes it possible to control the authorizations of deployments.
  • ASSIM signing ASSIM signing
  • a complete and authentic binary update content provided by a supplier cannot be consumed by a computer 2, 4, 6, 8 or 10 without this level of verification which makes it possible to ensure that only the images certified by the vehicle manufacturer can be broadcast to the vehicle. This also ensures the quality of the target software before deployment.
  • Each of these packages contains a digital signature ("digital signature" in English) used for the installation of computer components, as described below.
  • digital signatures in English
  • signature is used hereinafter to designate any digital signature.
  • ROOT.cert root certificate containing ROOT.md metadata and a ROOT.Kpub public key associated with a ROOT.Kpriv private key;
  • CA.cert authority certificate containing CA.md metadata, a CA.Kpub public key and a CA.sig signature;
  • a private key CA.Kpriv is associated with the public key CA.Kpub.
  • a private key R.Kpriv is associated with the public key R.Kpub.
  • associated public key and private key is meant here a public key and a private key associated in a public key infrastructure (or PKI for "Public Key Infrastructure”).
  • a data set can be signed by applying, to this data set, a cryptographic signature algorithm (here of RSA type) using the private key; the signature can then be verified by means of an associated cryptographic signature verification algorithm (here also of the RSA type), using the public key associated with the aforementioned private key.
  • a cryptographic signature algorithm here of RSA type
  • an associated cryptographic signature verification algorithm here also of the RSA type
  • the CA.sig signature of the CA.cert authority certificate is obtained by applying a cryptographic signature algorithm using the private key ROOT.Kpriv to the set formed of the CA.md metadata and the public key CA.Kpub (this operation being performed for example by a certification authority).
  • the signature R.sig of the manufacturer certificate R.cert is for its part obtained by applying a cryptographic signature algorithm using the private key CA.Kpriv to the set formed of the metadata R.md and of the public key R. Kpub (this operation can also be carried out by the aforementioned certification authority).
  • Each COMP computer component to be installed comprises:
  • COMPIND manifesto containing in particular a digest H (CONTEN) of the content to be installed and possibly a description of the computer component, for example a description of the functions updated by this component;
  • These data to be installed can constitute software or part of software (for example a software update). This software or this part of software is then designed to be executed at least in part by a processor of the electronic equipment concerned. As a variant, these data to be installed can be data to be stored (for example map data) for subsequent manipulation by a processor of the electronic equipment concerned.
  • the H hash (CONTEN) is obtained by applying a hash function (for example of the SHA-256 type) to the CONTEN content.
  • a hash function for example of the SHA-256 type
  • the SIG (COMPIND) signature is obtained by applying to the COMIND manifesto a cryptographic signature algorithm using the private key BK.Kpriv.
  • Each ECUPACK equipment package includes here:
  • an ECUPACKIND manifest comprising a hash H (COMP1), H (COMP2), H (COMPi) for each of the computer components COMP1, COMP2, COMPi contained in the ECUPACK equipment package, as well as possibly a vehicle identifier VIN and / or a description of the computer components COMP1, COMP2, COMPi contained in the package;
  • VIN identifier a SIG (ECUPACKIND) signature of the ECUPACKIND manifesto.
  • VIN identifier Several variants of making the VIN identifier available can be implemented.
  • the inclusion of the VIN identifier in the ECUPACK equipment package ensures that the computer component installed in the electronic equipment (for example a vehicle computer) is indeed the component assigned to this vehicle. Indeed, a component could very well be suitable for a multitude of vehicles of the same type, offering the possibility to a user, for example, of replacing a computer of his vehicle with a computer of another vehicle of the same type.
  • the inclusion of the VIN identifier in the ECUPACK equipment package makes it possible to prevent this manipulation.
  • the VIN identifier can be placed both in the DPACKIND manifesto and in the ECUPACKIND manifesto, or in neither of these two manifests, in particular for a computer component compatible with any vehicle , such as for example a computer component comprising cartographic data of a navigation system.
  • VIN V is a number uniquely associated with a vehicle, commonly referred to as VIN (for "Vehicle Identification NumbeT).
  • the condensates H (COMP1), H (COMP2), H (COMPi) are respectively obtained by applying a hash function (for example of the SHA-256 type) to the data constituting the computer component COMP1, COMP2, COMPi concerned, for example when defining the ECUPACK equipment package (depending on the needs of the equipment concerned, in particular the updating needs of this equipment).
  • a hash function for example of the SHA-256 type
  • the SIG (ECUPACKIND) signature is obtained by applying to the ECUPACKIND manifesto a cryptographic signature algorithm using the private key R.Kpriv (associated with the manufacturer certificate R.cert).
  • the SIG signature (ECUPACKIND) is for example contained in a dedicated field of the ECUPACK equipment package, for example a field in cms format (for "Syntax Message Cryptography").
  • this field can include the SIG signature (ECUPACKIND), the CA.cert authority certificate and the R.cert manufacturer certificate.
  • the DPACK download package includes:
  • a DPACKIND manifest including in particular a hash H (ECUPACK1), H (ECUPACK2), H (ECUPACKn) for each of the equipment packages ECUPACK1, ECUPACK2, ECUPACKn contained in the download package DPACK, as well as possibly a description of the packages of equipment ECUPACK1, ECUPACK2, ECUPACKn contained in the download packet DPACK (with for example an indication, for each equipment package ECUPACK1, ECUPACK2, ECUPACKn, of the electronic equipment recipient of the concerned equipment package);
  • the condensates H (ECUPACK1), H (ECUPACK2), H (ECUPACKn) are respectively obtained by applying a hash function (for example of SHA-256 type) to the equipment package ECUPACK2, ECUPACK2, ECUPACKn concerned , for example when defining the DPACK download package (after defining the targeted electronic devices and the respective needs of each of these devices).
  • a hash function for example of SHA-256 type
  • the SIG (DPACKIND) signature is obtained by applying to the DPACKIND manifesto a cryptographic signature algorithm using the private key R.Kpriv (associated with the manufacturer certificate R.cert).
  • the SIG signature (DPACKIND) is for example contained in a dedicated field of the DPACK download packet, for example a field in cms format (for "Cryprographic Message Syntax").
  • this field may include the SIG signature (DPACKIND), the CA.cert authority certificate and the R.cert manufacturer certificate.
  • each of the computer components COMP1, COMP2, COMPi is independent of the vehicle V targeted by the installation (and can for example be used for a fleet of vehicles) .
  • the equipment packages ECUPACK1, ECUPACK2, ECUPACKn are on the other hand specifically designed for the V vehicle.
  • Figure 3 shows a possible variant for the organization of data within the DPACK download package.
  • the vehicle identifier VIN is placed within the DPACKIND manifesto.
  • the computer components COMP1, COMP2, COMPi relating to a given electronic equipment item are not included in the equipment package ECUPACK1 intended for this electronic equipment item, but external to it, in order to possibly be able to be transmitted. separately from the ECUPACK1 equipment package, as explained below.
  • the ECUPACK1 equipment package in this case includes:
  • an ECUPACKIND manifest comprising a condensate H (COMP1), H (COMP2), H (COMPi) for each of the computer components COMP1, COMP2, COMPi associated with the electronic equipment concerned;
  • This method begins at step E2 during which the processing unit 4 sends a REQ request to the remote server S.
  • the vehicle V seeks to determine whether computer components are available for installation. within the vehicle V, for example for updating certain software components or certain data (such as data cartographic).
  • the REQ request is for example sent periodically by the processing unit 4.
  • electronic coordinates of the remote server S are for example stored within the processing unit 4 and used to transmit the REQ request to destination of the remote server S.
  • the electronic coordinates preferably refer to a secure connection such as SSL (well-known acronym for the English expression Secure Sockets Layer).
  • the REQ request can include the VIN identifier of the vehicle V.
  • the remote server S receives the REQ request in step E4 and determines (for example on the basis of the VIN identifier included in the REQ request) whether computer components are available for download for the vehicle V.
  • the server S therefore transmits in step E6 a global GLOB container to the processing unit 4.
  • This global GLOB container includes the DPACKIND manifesto, the associated signature SIG (DPACKIND) and the equipment packages ECUPACK1, ECUPACK2, ECUPACKn. Consequently, according to the embodiments, this global GLOB container includes or does not include the computer components COMP1, COMP2, COMPi.
  • step E6 it is also possible to transmit to this step E6 all or part of the computer components COMP1, COMP2, COMPi (these components transmitted to step E6 then not being transmitted to the step E26 described below).
  • These computer components can then be transmitted either within the ECUPACK equipment packets (for example within the framework of the data structure shown in FIG. 2), or alongside the concerned ECUPACK1 equipment packet (for example within the framework of the data structure shown in figure 3).
  • the global container GLOB transmitted to step E6 does not contain any of the computer components COMP1, COMP2, COMPi (these computer components then being transmitted during one or more steps in accordance with step E26 described below).
  • the processing unit 4 receives the global GLOB container in step E8 and can thus store it.
  • the GLOB global container is here received directly via the communication established between the remote server S and the vehicle V, this communication partly using in the present case a radio link between the vehicle V and the cellular telephone network already mentioned.
  • the global GLOB container (with or without computer components) could be received at step E8 from a memory card 20 inserted into reader 12 (and thereby connected to the processing unit 4) as indicated above. In this case, steps E2 to E6 are not implemented.
  • the memory size required within the unit processing 4 to store the received GLOB global container can be reduced. In other words, it is not necessary to provide within the processing unit 4 a buffer memory suitable for storing the entire DPACK download packet.
  • the processing unit 4 then proceeds to step E10 to verify the manufacturer's certificate R.cert (which notably contains the public key R.Kpub used below to verify signatures).
  • R.cert which notably contains the public key R.Kpub used below to verify signatures.
  • the R.cert certificate is here contained in a field in cms format of the DPACK download packet (and therefore of the global GLOB container received in step E8).
  • a cryptographic signature verification algorithm is applied using the public key CA.Kpub to the signature R.sig and to the signed data (here the metadata R.md and the public key R .Kpub).
  • the public key CA.Kpub is part of the CA.cert certificate, also contained here in the field in the above-mentioned CMS format.
  • the installation process is terminated, possibly with sending an error message to the remote S.
  • the processing unit can check whether the R.cert certificate has not expired by comparing the date and time at the instant concerned with the dates and times d 'expiration mentioned in R.md metadata.
  • the installation process is terminated, possibly with the sending of an error message to the remote server S.
  • step E12 the processing unit 4 proceeds to step E12 to verify the authority certificate CA.cert (which notably contains the public key CA.Kpub used as described above).
  • the CA.cert certificate is here contained in a field in cms format of the DPACK download packet (and therefore of the global GLOB container received in step E8).
  • a cryptographic signature verification algorithm is applied using the public key ROOT.Kpub to the CA.sig signature and to the signed data (here the CA.md metadata and the key public CA.Kpub).
  • a digest of the signed data is compared with the result obtained by applying to the signature CA.sig a cryptographic algorithm (here of the RSA type) using the public key ROOT.Kpub.
  • ROOT.Kpub is for example stored (during the manufacture of the processing unit 4) in a non-volatile memory of the processing unit 4.
  • the installation process is terminated, possibly with sending an error message to the remote S.
  • the processing unit can verify whether the CA.cert certificate has not expired by comparing the date and time at the relevant time to the expiration dates and times mentioned in the CA.md metadata.
  • the installation process is terminated, possibly with the sending of an error message to the remote server S. If the certificate has expired, the installation process is terminated, possibly with the sending of an error message to the remote server S. If the certificate is valid, the validity of the ROOT.cert root certificate can be checked in the same way by comparing the date and time at the given moment with the expiration dates and times of the ROOT.cert root certificate. mentioned in the ROOT.md metadata.
  • step E14 the processing unit 4 checks in step E14 certain parts of the global GLOB container received in step E8.
  • the processing unit verifies in particular in step E14 the integrity of the DPACKIND manifest (received in the global GLOB container).
  • the processing unit applies a cryptographic signature verification algorithm using the public key R.Kpub to the SIG signature (DPACKIND) and to the DPACKIND manifesto.
  • DPACKIND public key
  • DPACKIND manifesto a cryptographic algorithm (here of RSA type) using the public key R.Kpub. (Remember that the validity of the R.cert certificate containing the public key R.Kpub was checked in step E10.)
  • step E14 In the event of a positive verification at step E14 (that is to say in the event of equality at the step of comparing the aforementioned condensate and the aforementioned result), the installation process continues in step E16 described now.
  • the processing unit 4 distributes in step E16 various packages of ECUPACK equipment to the electronic equipment responsible for installing the computer components, here for example the first electronic control unit 6 and / or the gateway 8 .
  • Each ECUPACK equipment package contains the data of the global GLOB container intended for a particular electronic equipment item (here the first electronic control unit 6 or gateway 8), that is to say the data of the equipment package.
  • ECUPACKn intended for this electronic equipment, with or without the computer components COMP1, COMP2, COMPi themselves according to the embodiment concerned.
  • step E6 provision can in fact be made for all or part of the electronic components to be transmitted in the global GLOB container in step E6 and therefore for certain ECUPACK equipment packages at least to include one or more component (s). ) IT (s).
  • Each electronic item of equipment concerned thus receives an ECUPACK item of equipment in step E18.
  • the following describes the implementation of the method for such electronic equipment (here the first electronic control unit 6 or gateway 8), similar steps however being implemented in practice for other electronic equipment receiving a package of equipment. ECUPACK.
  • the electronic equipment (either here the first electronic control unit 6 or the gateway 8) can then optionally implement in step E20 a step of verifying the manufacturer certificate R.cert and the authority certificate. CA.cert. It is recalled that in the example described here, these R.cert and CA.cert certificates are part of a cms type field of the ECUPACK equipment package.
  • step E20 (performed by the electronic equipment 6, 8 concerned) are similar to that performed in steps E10 and E12 described above by the processing unit 4, and will therefore not be described. in detail here.
  • step E20 In the absence of verification at step E20, the installation process is terminated within the equipment 6, 8 concerned. An error message can also be sent to the processing unit 4 (for possible transmission to the remote server S, for example).
  • step E20 the electronic equipment item 6, 8 concerned proceeds to step E22 to verify the integrity of the ECUPACKIND manifest (received within the ECUPACKIND equipment package) .
  • the electronic equipment 6, 8 concerned applies a cryptographic signature verification algorithm using the public key R.Kpub to the signature SIG (ECUPACKIND) and to the ECUPACKIND manifesto.
  • ECUPACKIND signature SIG
  • ECUPACKIND manifesto a digest of the ECUPACKIND manifesto is compared with the result obtained by applying to the SIG signature (ECUPACKIND) a cryptographic algorithm (here of RSA type) using the public key R.Kpub.
  • step E22 In the event of a positive verification in step E22 (that is to say in the event of equality at the step of comparing the aforementioned condensate and the aforementioned result), the electronic equipment 6, 8 concerned verifies in step E24 if the VIN identifier of the vehicle V included in the ECUPACKIND manifest corresponds (that is to say in practice is equal) to the VIN identifier of the stored vehicle V (for example in a non-volatile memory ) within the electronic equipment 6, 8.
  • step E24 In the event of a positive verification at step E24 (that is to say in the event of equality between the VIN identifier indicated in the ECUPACKIND manifesto and the stored identifier), the installation can continue at step E32 described below (after receipt of the computer components as described now).
  • the remote server S sends in step E26 at least one computer component COMPi of the download package DPACK , intended for the processing unit 4.
  • this transmission from the computer component COMPi can be triggered following the reception by the remote server S of an indication coming from the processing unit 4, this indication for example indicating sufficient space in the buffer memory for storage of the computer component COMPi.
  • the processing unit 4 receives the computer component COMPi in step E28.
  • the processing unit 4 can optionally implement at step E29 a verification of the content of the concerned ECUPACKn equipment packet, for example by comparing the hash H (ECUPACKn) contained in the DPACKIND manifesto and a hash obtained by applying the hash function (here SHA256) to the ECUPACKn equipment packet as received .
  • a verification of the content of the concerned ECUPACKn equipment packet for example by comparing the hash H (ECUPACKn) contained in the DPACKIND manifesto and a hash obtained by applying the hash function (here SHA256) to the ECUPACKn equipment packet as received .
  • step E29 In the event of a positive verification at step E29 (that is to say in the event of equality between the hash H (ECUPACKn) of the DPACKIND manifesto and the hash obtained on the basis of the received ECUPACKn equipment package ), the computer component COMPi is distributed to the electronic equipment 6, 8 concerned in step E30.
  • the electronic equipment 6, 8 concerned thus receives the computer component COMPi in step E32.
  • the electronic equipment 6, 8 can then check this computer component COMPi.
  • the electronic equipment 6, 8 compares the condensate H (COMPi) contained in the ECUPACKIND manifesto and a condensate obtained by applying the hash function (here SHA256) to the component COMPi computer received. (Remember that the integrity of the ECUPACKIND manifesto was checked in step E22.)
  • step E34 In the event of a positive verification in step E34 (that is to say in the event of equality between the hash H (COMPi) contained in the ECUPACKIND manifest and the hash obtained), the verification of the computer component COMPi continues at step E36.
  • the electronic equipment 6, 8 firstly checks in step E36 the integrity of the manifest COMPIND of the computer component COMPi.
  • the electronic equipment 6, 8 concerned applies a cryptographic signature verification algorithm using the public key BK.Kpub to the SIG signature (COMPIND) and to the COMPIND manifest.
  • a cryptographic signature verification algorithm using the public key BK.Kpub to the SIG signature (COMPIND) and to the COMPIND manifest.
  • the public key BK.Kpub is for example stored in a non-volatile memory of the electronic equipment 6, 8 concerned.
  • the installation process of the computer component COMPi is terminated. , possibly with sending of an error message to the processing unit 4 (for possible transmission to the remote server S, for example).
  • the electronic equipment 6, 8 compares the hash H (CONTEN) contained in the COMPIND manifest and a hash obtained by applying the hash function (here SHA256) to the CONTEN content of the received computer component COMPi.
  • a step E38 can then be provided for waiting for the thermal engine to be put into operation (which in practice makes it possible to ensure that all the equipment electronics are in operation and that the COMPi computer component can be correctly installed in the equipment electronics concerned).
  • the electronic equipment 6, 8 concerned controls the installation of the computer component COMPi, that is to say the storage of the COMPi computer component in a non-volatile (rewritable) memory for later use.
  • the installation of the computer component COMPi is carried out within the electronic equipment itself (here the first electronic control unit 6) which has set up. carry out the preliminary verification steps E20 to E36 described above.
  • the electronic equipment responsible for the installation, and having in this context carried out the preliminary verification steps E20 to E36, command the installation of the computer component COMPi within another electronic device, here the second electronic control unit 10.
  • the gateway 8 thus controls, for example, the storage of the computer component COMPi in a non-volatile (rewritable) memory of the second electronic control unit 10.
  • a step E42 can be used to wait for the operation of the heat engine to stop.
  • the processing unit 4 displays on a user interface (for example a screen placed in the passenger compartment vehicle V) an indication that computer components have been installed and are ready to be used (step E44).
  • a user interface for example a screen placed in the passenger compartment vehicle V
  • the processing unit 4 then waits in step E46 for a response from the user (for example the driver of the vehicle V), for example via the aforementioned user interface (possibly the aforementioned screen when this screen is displayed. touch).
  • step E40 In the event of a negative response from the user, the computer component (s) installed in step E40 is (are) not used.
  • the processing unit 4 transmits, to the various electronic equipment items concerned (here the first electronic control unit 6 and, via the gateway 8, the second electronic control unit 10), a CMD command for activating the computer components installed (step E48).
  • the installed computer components are then activated (step E50).
  • instructions included in the relevant computer component can then be executed by the processor of the electronic equipment 6, 10 in which the computer component has been installed.
  • data included in the relevant computer component can be manipulated by the processor of the electronic equipment 6, 10 in which the computer component has been installed.

Landscapes

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

Abstract

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

Description

DESCRIPTION
TITRE DE L’INVENTION : PROCÉDÉ D’INSTALLATION D’UN COMPOSANT INFORMATIQUE ET
EQUIPEMENT ELECTRONIQUE ASSOCIE
DOMAINE TECHNIQUE DE L'INVENTION
[0001 ] La présente invention concerne de manière générale l’installation des composants informatiques au sein des véhicules, en particulier des véhicules automobiles.
[0002] Elle trouve une application particulièrement avantageuse dans le cadre du téléchargement d’un tel composant informatique au sein d’un véhicule, mais s’applique également lorsque le composant informatique est chargé localement dans le véhicule, par exemple à partir d’une carte mémoire.
[0003] Elle concerne plus particulièrement un procédé d’installation d’un composant informatique et un équipement électronique associé.
ETAT DE LA TECHNIQUE
[0004] On cherche dans certaines situations à installer un composant informatique dans un équipement électronique équipant un véhicule. C’est notamment le cas lorsque l’on souhaite mettre à jour un logiciel exécuté au sein de l’équipement électronique ou des données manipulées par l’équipement électronique.
[0005] Une telle installation de composant informatique a naturellement des conséquences sur le fonctionnement ultérieur du véhicule et doit être réalisée de manière contrôlée.
PRESENTATION DE L'INVENTION
[0006] Dans ce contexte, la présente invention propose un procédé d’installation d’un composant informatique dans un équipement électronique équipant un véhicule, comprenant des étapes consistant à :
- recevoir un paquet d’équipement comprenant un premier manifeste incluant un condensât du composant informatique ;
- vérifier l’intégrité du premier manifeste ;
- recevoir le composant informatique ;
- vérifier la correspondance entre le condensât du composant informatique et le composant informatique reçu ; - installer le composant informatique seulement en cas de vérification positive de l’intégrité du premier manifeste et de vérification positive de la correspondance.
[0007] Ainsi, grâce à l’invention, le véhicule reçoit une structure de données associée au composant informatique et participant (à l’aide notamment du condensât) à la vérification de l’intégrité du composant informatique. La solution proposée rend en outre possible la transmission séparée du paquet d’équipement et du composant informatique lui-même, ce qui donne plus de souplesse lors de la conception du véhicule et de ses équipements électroniques.
[0008] On peut prévoir par ailleurs que le premier manifeste susmentionné inclue un premier identifiant de véhicule et que le procédé d’installation comprenne alors des étapes consistant à :
- comparer le premier identifiant de véhicule à un second identifiant de véhicule mémorisé au sein du véhicule ;
- installer le composant informatique seulement en cas de comparaison positive du premier identifiant et du second identifiant.
[0009] D’autres caractéristiques avantageuses et non limitatives du procédé conforme à l’invention, prises individuellement ou selon toutes les combinaisons techniquement possibles, sont les suivantes :
[0010] - le paquet d’équipement comprend une première signature ;
[0011 ] - l’intégrité du manifeste est vérifiée en appliquant un algorithme cryptographique de vérification de signature à la première signature et au premier manifeste ;
[0012] - le composant informatique est reçu indépendamment du paquet d’équipement ;
[0013] - le composant informatique est reçu au sein du paquet d’équipement ;
[0014] - le composant informatique comprend une seconde signature et un contenu ;
[0015] - le procédé comprend une étape de vérification de l’intégrité du contenu au moyen de la seconde signature.
[0016] Le procédé peut comprendre par ailleurs des étapes consistant à :
- recevoir un conteneur comprenant ledit paquet d’équipement et un deuxième manifeste ;
- vérification de l’intégrité du deuxième manifeste.
[0017] Ce deuxième manifeste peut alors comprendre un premier identifiant de véhicule et le procédé d’installation peut dans ce cas comprendre des étapes consistant à :
- comparer le premier identifiant de véhicule à un second identifiant de véhicule mémorisé au sein du véhicule ;
- transmettre le paquet d’équipement seulement en cas de comparaison positive du premier identifiant et du second identifiant.
[0018] Le conteneur peut alors par exemple comprendre un autre paquet d’équipement destiné à un autre équipement électronique.
[0019] Ce conteneur peut par ailleurs être reçu en provenance d’un serveur distant (par exemple directement via une communication établie entre le serveur distant et le véhicule, cette communication pouvant utiliser en partie une liaison radio entre le véhicule et un réseau cellulaire de téléphonie) en réponse à une requête émise par le véhicule ; en variante, le conteneur peut être reçu d’une carte mémoire insérée dans un lecteur équipant le véhicule.
[0020] L’invention concerne enfin un équipement électronique destiné à équiper un véhicule et comprenant :
- un module de réception d’un paquet d’équipement comprenant un manifeste incluant un condensât d’un composant informatique ;
- un module de vérification de l’intégrité du manifeste ;
- un module de réception du composant informatique ;
- un module de vérification de la correspondance entre le condensât du composant informatique et le composant informatique reçu ;
- un module d’installation conçu pour installer le composant informatique seulement en cas de vérification positive de l’intégrité du manifeste et de vérification positive de la correspondance.
[0021 ] On peut prévoir par ailleurs que le manifeste inclue un premier identifiant de véhicule et l’équipement électronique peut alors comprendre un module de comparaison du premier identifiant de véhicule et d’un second identifiant du véhicule mémorisé au sein du véhicule.
[0022] Le module d’installation peut être conçu pour installer le composant informatique seulement en cas de vérification positive de l’intégrité du manifeste, de comparaison positive du premier identifiant et du second identifiant, et de vérification positive de la correspondance.
[0023] Au-delà de la protection d’intégrité et d’authenticité qu’amène la vérification du manifeste, l’usage de l’identifiant du véhicule ciblé dans ce dernier permet de rajouter une protection de légitimité. En effet, le processus de mise à jour embarqué peut certes vérifier qu’une image reçue est intègre, authentique et compatible sur un matériel donné mais cela n’implique pas forcément pour autant que ledit véhicule soit légitime à la recevoir. Dans le cas d’une cyber attaque ou processus malveillant dans la chaîne de transmission de bout en bout, une image d’un véhicule compatible pourrait être insérée en lieu et place de l’image source. L’identifiant du véhicule dans le manifeste permettra donc de ne pas être trompé lors de ce scénario.
[0024] Un tel équipement électronique est par exemple une unité électronique de commande (ou calculateur) comprenant un processeur et une mémoire mémorisant des instructions de programme d’ordinateur exécutables par le processeur.
[0025] Les modules précités sont par exemple mis en œuvre ici par la coopération du processeur et de certaines instructions conçues pour mettre en œuvre la fonctionnalité attribuée au module concerné (comme décrit plus loin) lorsque ces instructions sont exécutées par le processeur.
[0026] Bien entendu, les différentes caractéristiques, variantes et formes de réalisation de l'invention peuvent être associées les unes avec les autres selon diverses combinaisons dans la mesure où elles ne sont pas incompatibles ou exclusives les unes des autres.
DESCRIPTION DETAILLEE DE L'INVENTION
[0027] La description qui va suivre en regard des dessins annexés, donnés à titre d’exemples non limitatifs, fera bien comprendre en quoi consiste l’invention et comment elle peut être réalisée.
[0028] Sur les dessins annexés :
[0029] La figure 1 représente schématiquement un système dans lequel peut être mise en œuvre l’invention ;
[0030] La figure 2 représente un exemple d’organisation de données utilisable dans le cadre de l’invention ;
[0031 ] La figure 3 représente un autre exemple d’organisation de données utilisable dans le cadre de l’invention ; et
[0032] La figure 4 présente un exemple de procédé d’installation de composants informatiques au sein d’un véhicule conforme à l’invention.
[0033] Le système de la figure 1 comprend un véhicule V (par exemple un véhicule automobile), un réseau de téléphonie mobile N, un réseau étendu I (tel que le réseau Internet) et un serveur distant S.
[0034] Le véhicule V comprend une unité de communication 2, une unité de traitement 4, une première unité électronique de commande 6, une passerelle 8 et une seconde unité électronique de commande 10.
[0035] On a représenté sur la figure 1 les éléments du véhicule V utiles à la compréhension de l’invention, mais le véhicule V comprend bien entendu en pratique d’autres éléments, notamment d’autres unités électroniques de commande ou calculateurs.
[0036] Les équipements électroniques mentionnés ci-dessus (unité de communication 2, unité de traitement 4, première unité électronique de commande 6, passerelle 8 et seconde unité électronique de commande 10) peuvent chacun être réalisés en pratique sous forme d’une architecture à microprocesseur ; dans ce contexte notamment, chacun de ces équipements électroniques comprend un processeur et au moins une mémoire (par exemple une mémoire vive et/ou une mémoire non-volatile).
[0037] L’unité de traitement 4 peut elle-même être mise en oeuvre en pratique au moyen d’une unité électronique de commande, ayant éventuellement d’autres fonctionnalités que celles décrites ci-dessous.
[0038] Comme représenté schématiquement en figure 1 , l’unité de traitement 4 est reliée à l’unité de communication 2, à la première unité électronique de commande 6 et à la passerelle 8 afin de pouvoir échanger des données avec ces différents équipements électroniques. L’unité de communication 2, l’unité de traitement 4, l’unité électronique de commande 6 et la passerelle 8 sont par exemple pour ce faire connectée à un (même) réseau informatique embarqué (non représenté), par exemple un bus CAN (pour "Controller Area Network).
[0039] La passerelle 8 est par ailleurs reliée à la seconde unité électronique de commande 10, par exemple au moyen d’un bus dédié.
[0040] Le véhicule V peut comprendre en outre un lecteur 12 d’une carte mémoire 20, utilisable dans une variante de réalisation de l’invention, comme mentionné plus loin.
[0041 ] L’unité de communication 2 est conçue pour mettre en oeuvre une communication C (comme représenté schématiquement en figure 1 par une ligne en trait plein qui signifie que cette connexion est de type physique, par exemple 3G/4G, WiFi ou autre) dans le réseau de téléphonie mobile N et peut ainsi établir une connexion avec le serveur distant S via le réseau de téléphonie mobile N (en utilisant notamment une liaison radio entre le véhicule V et un réseau cellulaire de téléphonie faisant partie du réseau de téléphonie mobile N) et le réseau étendu I, de sorte que l’unité de traitement 4 et le serveur distant S peuvent échanger des données D (comme représenté schématiquement en figure 1 par une ligne pointillée qui signifie que cette connexion est de type logique), notamment dans le cadre de l’installation de composants informatiques au sein du véhicule V, comme décrit ci- après.
[0042] La figure 2 représente un exemple d’organisation de données, utilisable dans le cadre de l’invention.
[0043] Ces données comprennent notamment des composants informatiques COMP1 , COMP2, COMPi que l’on souhaite installer dans un ou plusieurs équipement(s) électronique(s) du véhicule V, ici notamment dans la première unité électronique de commande 6 et/ou dans la seconde unité électronique de commande 10, désignées l’une et l’autre par le vocable « équipement électronique ».
[0044] Les composants informatiques COMP1 , COMP2, COMPi sont ici encapsulés au sein d’une structure arborescente comme suit :
- un paquet de téléchargement DPACK comprend un ou plusieurs paquet(s) d’équipement ECUPACK1 , ECUPACK2, ECUPACKn relatif(s) (chacun) à un équipement électronique du véhicule V ;
- chaque paquet d’équipement ECUPACK comprend des données relatives à un ou plusieurs composant(s) informatique(s) COMP1 , COMP2, COMPi destiné(s) à un équipement électronique particulier.
[0045] Ce procédé d’encapsulation de type poupées russes est particulièrement avantageux car au-delà du fait qu’il permet une ségrégation de contenu par pièce cible, c’est-à-dire ici par unité électronique de commande 2,4, 6, 8 et 10 dont le logiciel est modifiable par mise à jour à distance (ou firmware over the air en anglais, FOTA), il permet aussi de garantir une cohérence de mise à jour au sein d’une même pièce électronique. En outre, cette encapsulation permet d’avoir des niveaux de vérification d’intégrité/authenticité à plusieurs étages. Plus précisément, l’unité de communication 2 pourra faire une vérification de 1 er niveau sur le paquet de téléchargement DPACK et dès lors que cette vérification est validée les paquet(s) d’équipement ECUPACK seront extraits et distribués aux pièces cibles 2,4, 6, 8 et 10. Les pièces cibles 2, 4, 6, 8 et 10 pourront alors effectuer une vérification de niveau 2, avec du matériel cryptographique différent, permettant de créer une isolation de contenu par pièce (dont les fournisseurs peuvent être multiples). Une fois les paquet(s) d’équipement ECUPACK authentifiés, les composants informatiques COMP1 , COMP2, COMPi peuvent être extraits, validés à leur tour par un 3ième niveau cryptographique et être au final installés en cas de vérification positive. Ce procédé est donc particulièrement avantageux si le calculateur cible est l’unité de communication 2, car pour cette dernière, qui est souvent composée d’une zone sécurisée ou protégée (ou trusted zone en anglais) et d’une zone non sécurisée (ou untrusted zone en anglais), le procédé permet alors, comme un calculateur distant, de faire une vérification à 2 niveaux : le paquet de téléchargement DPACK est vérifié dans la zone connectée non sécurisée, le paquet d’équipement ECUPACK est extrait et partagé à la zone sécurisée, et la vérification de ce dernier sera faite en zone sécurisée. Ainsi, au final, que l’ECU cible soit local ou distant (autre ECU du réseau véhicule), le procédé permet une vérification à plusieurs niveaux. Dans l’alternative également représentée sur la figure 2 où un composant COMP n’est pas dans le paquet d’équipement ECUPACK , il sera reçu par un process d’échange secondaire et validé par le condensât H(COMP1 ),H(COMP2), H(COMPi) contenu en première instance dans le paquet d’équipement ECUPACK. L’encapsulation des contenus de mise à jour, ou content en anglais, dans un composant permet de gérer une signature électronique de niveau constructeur afin de s’assurer de la certification des images pour assurer contrôle du déploiement. Cette opération de signature des composants sera réalisée, par exemple de façon manuelle, par un agent de sécurité certifié (avec des privilèges spécifiques) chez le constructeur du véhicule. Sans cette opération, un contenu intègre ne peut être déployé sur un véhicule. Ce niveau de signature est par exemple manuel (notamment ASSIM signing), et permet de contrôler les autorisations de déploiements. Ainsi, un contenu de mise à jour binaire intègre et authentique fourni par un fournisseur ne pourra pas être consommé par un calculateur 2, 4, 6, 8 ou 10 sans ce niveau de vérification qui permet de s’assurer que seules les images certifiées par le constructeur du véhicule peuvent être diffusées vers le véhicule. Cela permet en outre de s’assurer de la qualité du logiciel cible avant déploiement. [0046] Chacun de ces paquets contient une signature numérique ("digital signature" en anglais) utilisée en vue de l’installation des composants informatiques, comme décrit dans la suite. La vérification des signatures numériques, telle qu’envisagée plus bas, nécessite une infrastructure cryptographique particulière, décrite à présent.
[0047] Pour alléger la présentation, on désigne simplement par " signature " dans la suite toute signature numérique.
[0048] Sont utilisés en particulier dans la suite :
- un certificat racine ROOT.cert contenant des métadonnées ROOT.md et une clé publique ROOT.Kpub associée à une clé privée ROOT.Kpriv ;
- un certificat d’autorité CA.cert contenant des métadonnées CA.md, une clé publique CA.Kpub et une signature CA.sig ;
- un certificat constructeur R.cert contenant des métadonnées R.md, une clé publique R.Kpub et une signature R.sig ;
- une clé publique BK.Kpub associée à une clé privée BK.Kpriv.
[0049] Une clé privée CA.Kpriv est associée à la clé publique CA.Kpub.
[0050] De même, une clé privée R.Kpriv est associée à la clé publique R.Kpub.
[0051 ] Par clé publique et clé privée associées, on entend ici une clé publique et une clé privée associées dans une infrastructure à clé publique (ou PKI pour "Public Key Infrastructure").
[0052] Dans un tel contexte, un ensemble de données peut être signé par application, à cet ensemble de données, d’un algorithme cryptographique de signature (ici de type RSA) utilisant la clé privée ; la signature peut alors être vérifiée au moyen d’un algorithme cryptographique de vérification de signature associé (ici donc également de type RSA), en utilisant le clé publique associée à la clé privée précitée.
[0053] La signature CA.sig du certificat d’autorité CA.cert est obtenue en appliquant un algorithme cryptographique de signature utilisant la clé privée ROOT.Kpriv à l’ensemble formé des métadonnées CA.md et de la clé publique CA.Kpub (cette opération étant réalisée par exemple par une autorité de certification).
[0054] La signature R.sig du certificat constructeur R.cert est quant à elle obtenue en appliquant un algorithme cryptographique de signature utilisant la clé privée CA.Kpriv à l’ensemble formé des métadonnées R.md et de la clé publique R.Kpub (cette opération pouvant elle aussi être réalisée par l’autorité de certification précitée).
[0055] On décrit à présent en détail les différentes structures de données représentée à la figure 2.
[0056] Chaque composant informatique COMP à installer comprend :
- un contenu CONTEN comprenant les données à installer (en pratique à mémoriser) dans l’équipement électronique concerné ;
- un manifeste COMPIND, contenant notamment un condensât H(CONTEN) du contenu à installer et éventuellement un descriptif du composant informatique, par exemple un descriptif des fonctions mises à jour par ce composant ;
- une signature SIG(COMPIND) du manifeste COMPIND.
[0057] Ces données à installer peuvent constituer un logiciel ou une partie d’un logiciel (par exemple une mise à jour du logiciel). Ce logiciel ou cette partie de logiciel est alors conçu(e) pour être exécuté(e) au moins en partie par un processeur de l’équipement électronique concerné. En variante, ces données à installer peuvent être des données à mémoriser (par exemple des données cartographiques) pour manipulation ultérieure par un processeur de l’équipement électronique concerné.
[0058] Le condensât H(CONTEN) est obtenu par application d’une fonction de hachage (par exemple de type SHA-256) au contenu CONTEN.
[0059] La signature SIG(COMPIND) est obtenue par application au manifeste COMIND d’un algorithme cryptographique de signature utilisant la clé privée BK.Kpriv.
[0060] Ces opérations sont par exemple effectuées par un organisme de certification du contenu CONTEN (par exemple du logiciel) concerné.
[0061 ] Chaque paquet d’équipement ECUPACK comprend ici :
- un ou plusieurs composant(s) informatique(s) COMP1 , COMP2, COMPi tel que décrit ci-dessus ;
- un manifeste ECUPACKIND comprenant un condensât H(COMP1 ), H(COMP2), H(COMPi) pour chacun des composants informatiques COMP1 , COMP2, COMPi contenus dans le paquet d’équipement ECUPACK, ainsi qu’éventuellement un identifiant VIN de véhicule et/ou un descriptif des composants informatiques COMP1 , COMP2, COMPi contenus dans le paquet ;
- une signature SIG(ECUPACKIND) du manifeste ECUPACKIND. [0062] Plusieurs variantes de mise à disposition de l’identifiant VIN peuvent être mises en oeuvre. L’inclusion de l’identifiant VIN dans le paquet d’équipement ECUPACK, comme mentionné ci-dessus, permet d’assurer que le composant informatique installé dans l’équipement électronique (par exemple un calculateur du véhicule) est bien le composant attribué à ce véhicule. En effet, un composant pourrait très bien convenir à une multitude de véhicules d’un même type, offrant la possibilité à un utilisateur par exemple de remplacer un calculateur de son véhicule par un calculateur d’un autre véhicule de même type. L’inclusion de l’identifiant VIN dans le paquet d’équipement ECUPACK permet d’empêcher cette manipulation.
[0063] En variante toutefois, on peut cependant autoriser cette manipulation, par exemple en plaçant l’identifiant VIN de véhicule au sein du manifeste DPACKIND décrit plus bas, comme c’est le cas dans la variante représentée en figure 3. Dans ce cas, on peut envisager de ne transmettre (au moyen de l’unité de traitement 4) le paquet d’équipement ECUPACK à l’équipement électronique concerné qu’en cas de comparaison positive entre l’identifiant VIN reçu au sein du manifeste DPACKIND et l’identifiant du véhicule V tel que mémorisé (ici au sein de l’unité de traitement 4).
[0064] Selon d’autres modes de réalisation envisageables, l’identifiant VIN peut être placé à la fois dans le manifeste DPACKIND et dans le manifeste ECUPACKIND, ou dans aucun de ces deux manifestes, en particulier pour un composant informatique compatible à tout véhicule, comme par exemple un composant informatique comprenant des données cartographiques d’un système de navigation.
[0065] Ici, l’identifiant VIN de véhicule V est un nombre associé de manière unique à un véhicule, couramment désigné sous l’appellation VIN (pour "Vehicle Identification NumbeT).
[0066] Les condensais H(COMP1 ), H(COMP2), H(COMPi) sont respectivement obtenus par application d’une fonction de hachage (par exemple de type SHA-256) aux données constituant le composant informatique COMP1 , COMP2, COMPi concerné, par exemple lors de la définition du paquet d’équipement ECUPACK (en fonction des besoins de l’équipement concerné, notamment des besoins de mise à jour de cet équipement).
[0067] La signature SIG(ECUPACKIND) est obtenue par application au manifeste ECUPACKIND d’un algorithme cryptographique de signature utilisant la clé privée R.Kpriv (associée au certificat constructeur R.cert).
[0068] Ces opérations sont par exemple effectuées par le constructeur automobile (ou pour le compte du constructeur automobile) lorsque sont définis les composants informatiques à installer pour l’équipement électronique concerné dans un véhicule donné (identifié par l’identifiant VIN).
[0069] En pratique, la signature SIG(ECUPACKIND) est par exemple contenue dans un champ dédié du paquet d’équipement ECUPACK, par exemple un champ au format cms (pour " Cryptographie Message Syntax"). Dans ce cas, ce champ peut comprendre la signature SIG(ECUPACKIND), le certificat d’autorité CA.cert et le certificat constructeur R.cert.
[0070] Le paquet de téléchargement DPACK comprend :
- un ou plusieurs paquet(s) d’équipement ECUPACK1 , ECUPACK2, ECUPACKn tel(s) que décrit(s) ci-dessus ;
- un manifeste DPACKIND comprenant notamment un condensât H(ECUPACK1 ), H(ECUPACK2), H(ECUPACKn) pour chacun des paquets d’équipement ECUPACK1 , ECUPACK2, ECUPACKn contenus dans le paquet de téléchargement DPACK, ainsi qu’éventuellement un descriptif des paquets d’équipement ECUPACK1 , ECUPACK2, ECUPACKn contenus dans le paquet de téléchargement DPACK (avec par exemple une indication, pour chaque paquet d’équipement ECUPACK1 , ECUPACK2, ECUPACKn, de l’équipement électronique destinataire du paquet d’équipement concerné) ;
- une signature SIG(DPACKIND) du manifeste DPACKIND.
[0071 ] Les condensais H(ECUPACK1 ), H(ECUPACK2), H(ECUPACKn) sont respectivement obtenus par application d’une fonction de hachage (par exemple de type SHA-256) au paquet d’équipement ECUPACK2, ECUPACK2, ECUPACKn concerné, par exemple lors de la définition du paquet de téléchargement DPACK (après définition des équipements électroniques visés et des besoins respectifs de chacun de ces équipements).
[0072] La signature SIG(DPACKIND) est obtenue par application au manifeste DPACKIND d’un algorithme cryptographique de signature utilisant la clé privée R.Kpriv (associée au certificat constructeur R.cert).
[0073] Ces opérations sont par exemple effectuées par le constructeur automobile (ou pour le compte du constructeur automobile) lorsque sont définis les équipements électroniques concernées et les composants informatiques à installer dans ces équipements électroniques.
[0074] En pratique, la signature SIG(DPACKIND) est par exemple contenue dans un champ dédié du paquet de téléchargement DPACK, par exemple un champ au format cms (pour "Cryprographic Message Syntax”). Dans ce cas, ce champ peut comprendre la signature SIG(DPACKIND), le certificat d’autorité CA.cert et le certificat constructeur R.cert.
[0075] On remarque que, dans l’architecture qui vient d’être décrite, chacun des composants informatiques COMP1 , COMP2, COMPi est indépendant du véhicule V visé par l’installation (et peut par exemple être utilisé pour une flotte de véhicules). Les paquets d’équipement ECUPACK1 , ECUPACK2, ECUPACKn (et par conséquent le paquet de téléchargement DPACK) sont en revanche spécifiquement conçus pour le véhicule V.
[0076] La figure 3 présente une variante envisageable pour l’organisation des données au sein du paquet de téléchargement DPACK.
[0077] Comme déjà indiqué, dans cette variante, l’identifiant VIN de véhicule est placé au sein du manifeste DPACKIND.
[0078] Par ailleurs, les composants informatiques COMP1 , COMP2, COMPi relatifs à un équipement électronique donné ne sont pas compris dans le paquet d’équipement ECUPACK1 destiné à cet équipement électronique, mais extérieurs à celui-ci, afin de pouvoir éventuellement être transmis séparément du paquet d’équipement ECUPACK1 , comme expliqué plus bas.
[0079] Le paquet d’équipement ECUPACK1 comprend dans ce cas :
- un manifeste ECUPACKIND comprenant un condensât H(COMP1 ), H(COMP2), H(COMPi) pour chacun des composants informatiques COMP1 , COMP2, COMPi associés à l’équipement électronique concerné ;
- une signature SIG(ECUPACKIND) du manifeste ECUPACKIND.
[0080] On décrit à présent en référence à la figure 4 un exemple de procédé d’installation de composants informatiques au sein du véhicule V conforme à l’invention.
[0081 ] Ce procédé débute à l’étape E2 au cours de laquelle l’unité de traitement 4 émet une requête REQ à destination du serveur distant S. Par cette requête, le véhicule V cherche à déterminer si des composants informatiques sont disponibles pour installation au sein du véhicule V, par exemple pour mise à jour de certains composants logiciels ou de certaines données (telles que des données cartographiques).
[0082] La requête REQ est par exemple émise périodiquement par l’unité de traitement 4. En pratique, des coordonnées électroniques du serveur distant S sont par exemple mémorisées au sein de l’unité de traitement 4 et utilisées pour transmettre la requête REQ à destination du serveur distant S. Les coordonnées électroniques font de préférence référence à une connexion sécurisée telle que SSL (acronyme bien connu de l’expression anglaise Secure Sockets Layer).
[0083] La requête REQ peut inclure l’identifiant VIN du véhicule V.
[0084] Le serveur distant S reçoit la requête REQ à l’étape E4 et détermine (par exemple sur la base de l’identifiant VIN inclus dans la requête REQ) si des composants informatiques sont disponibles pour téléchargement pour le véhicule V.
[0085] On suppose ici que des composants informatiques sont disponibles pour téléchargement et installation dans le véhicule V. Le serveur S transmet par conséquent à l’étape E6 un conteneur global GLOB à l’unité de traitement 4.
[0086] Ce conteneur global GLOB comprend le manifeste DPACKIND, la signature associée SIG(DPACKIND) et les paquets d’équipement ECUPACK1 , ECUPACK2, ECUPACKn. Par conséquent, selon les modes de réalisation, ce conteneur global GLOB comprend ou ne comprend pas les composants informatiques COMP1 , COMP2, COMPi.
[0087] En effet, selon une première possibilité de réalisation, on peut également transmettre à cette étape E6 tout ou partie des composants informatiques COMP1 , COMP2, COMPi (ces composants transmis à l’étape E6 n’étant alors pas transmis à l’étape E26 décrite plus bas). Ces composants informatiques peuvent alors être transmis soit au sein des paquets d’équipements ECUPACK (par exemple dans le cadre de la structure de données représentée en figure 2), soit à côté du paquet d’équipements ECUPACK1 concerné (par exemple dans le cadre de la structure de données représentée en figure 3).
[0088] Selon une seconde possibilité de réalisation, le conteneur global GLOB transmis à l’étape E6 ne contient aucun des composants informatiques COMP1 , COMP2, COMPi (ces composants informatiques étant alors transmis lors d’une ou plusieurs étapes conforme(s) à l’étape E26 décrite plus bas).
[0089] L’unité de traitement 4 reçoit le conteneur global GLOB à l’étape E8 et peut ainsi mémoriser celui-ci. Le conteneur global GLOB est ici reçu directement via la communication établie entre le serveur distant S et le véhicule V, cette communication utilisant en partie dans le cas présent une liaison radio entre le véhicule V et le réseau cellulaire de téléphonie déjà mentionné.
[0090] En variante, le conteneur global GLOB (avec ou sans composants informatiques) pourrait être reçu à l’étape E8 en provenance d’une carte mémoire 20 insérée dans le lecteur 12 (et connectée par ce biais à l’unité de traitement 4) comme indiqué plus haut. Les étapes E2 à E6 ne sont dans ce cas pas mises en œuvre.
[0091 ] On remarque que, dans les modes de réalisation où le conteneur global GLOB transmis ne contient pas les composants informatiques COMP1 , COMP2, COMPi (ou certains au moins d’entre eux), la taille mémoire requise au sein de l’unité de traitement 4 pour mémoriser le conteneur global GLOB reçu peut être réduite. Autrement dit, il n’est pas nécessaire de prévoir au sein de l’unité de traitement 4 une mémoire tampon adaptée à mémoriser l’ensemble du paquet de téléchargement DPACK.
[0092] L’unité de traitement 4 procède alors à l’étape E10 à la vérification du certificat constructeur R.cert (qui contient notamment la clé publique R.Kpub utilisée dans la suite pour vérifier des signatures).
[0093] Comme indiqué plus haut, le certificat R.cert est ici contenu dans un champ au format cms du paquet de téléchargement DPACK (et donc du conteneur global GLOB reçu à l’étape E8).
[0094] Pour vérifier le certificat constructeur R.cert, on applique un algorithme cryptographique de vérification de signature utilisant la clé publique CA.Kpub à la signature R.sig et aux données signées (ici les métadonnées R.md et la clé publique R.Kpub). (On rappelle que la clé publique CA.Kpub fait partie du certificat CA.cert, contenu lui-aussi ici dans le champ au format CMS susmentionné.) En pratique, on compare par exemple un condensât des données signées et le résultat obtenu par application à la signature R.sig d’un algorithme cryptographique (ici de type RSA) utilisant la clé publique CA.Kpub.
[0095] En l’absence de vérification (c’est-à-dire en cas d’inégalité à l’étape de comparaison du condensât précité et du résultat précité), il est mis fin au processus d’installation, éventuellement avec envoi d’un message d’erreur à destination du serveur distant S.
[0096] En cas de vérification positive à l’étape E10 (c’est-à-dire en cas d’égalité à l’étape de comparaison du condensât précité et du résultat précité), l’unité de traitement peut vérifier si le certificat R.cert n’a pas expiré en comparant la date et l’heure à l’instant concerné aux dates et heures d’expiration mentionnées dans les métadonnées R.md.
[0097] Si le certificat est expiré, il est mis fin au processus d’installation, éventuellement avec envoi d’un message d’erreur à destination du serveur distant S.
[0098] Si le certificat est valide, l’unité de traitement 4 procède à l’étape E12 à la vérification du certificat d’autorité CA.cert (qui contient notamment la clé publique CA.Kpub utilisée comme décrit ci-dessus).
[0099] Comme indiqué plus haut, le certificat CA.cert est ici contenu dans un champ au format cms du paquet de téléchargement DPACK (et donc du conteneur global GLOB reçu à l’étape E8).
[0100] Pour vérifier le certificat d’autorité CA.cert, on applique un algorithme cryptographique de vérification de signature utilisant la clé publique ROOT.Kpub à la signature CA.sig et aux données signées (ici les métadonnées CA.md et la clé publique CA.Kpub). En pratique, on compare par exemple un condensât des données signées et le résultat obtenu par application à la signature CA.sig d’un algorithme cryptographique (ici de type RSA) utilisant la clé publique ROOT.Kpub.
[0101 ] La clé publique ROOT.Kpub est par exemple mémorisée (lors de la fabrication de l’unité de traitement 4) au sein d’une mémoire non-volatile de l’unité de traitement 4.
[0102] En l’absence de vérification (c’est-à-dire en cas d’inégalité à l’étape de comparaison du condensât précité et du résultat précité), il est mis fin au processus d’installation, éventuellement avec envoi d’un message d’erreur à destination du serveur distant S.
[0103] En cas de vérification positive à l’étape E12 (c’est-à-dire en cas d’égalité à l’étape de comparaison du condensât précité et du résultat précité), l’unité de traitement peut vérifier si le certificat CA.cert n’a pas expiré en comparant la date et l’heure à l’instant concerné aux dates et heures d’expiration mentionnées dans les métadonnées CA.md.
[0104] Si le certificat est expiré, il est mis fin au processus d’installation, éventuellement avec envoi d’un message d’erreur à destination du serveur distant S. [0105] Si le certificat est valide, on peut vérifier de la même manière la validité du certificat racine ROOT.cert en comparant la date et l’heure à l’instant donné aux dates et heures d’expiration du certificat racine ROOT.cert mentionnées dans les métadonnées ROOT.md.
[0106] Si le certificat est expiré, il est mis fin au processus d’installation, éventuellement avec envoi d’un message d’erreur à destination du serveur distant S.
[0107] Si le certificat est valide, l’unité de traitement 4 vérifie à l’étape E14 certaines parties du conteneur global GLOB reçu à l’étape E8.
[0108] L’unité de traitement vérifie en particulier à l’étape E14 l’intégrité du manifeste DPACKIND (reçu dans le conteneur global GLOB).
[0109] Pour ce faire, l’unité de traitement applique un algorithme cryptographique de vérification de signature utilisant la clé publique R.Kpub à la signature SIG(DPACKIND) et au manifeste DPACKIND. En pratique, on compare par exemple un condensât du manifeste DPACKIND et le résultat obtenu par application à la signature SIG(DPACKIND) d’un algorithme cryptographique (ici de type RSA) utilisant la clé publique R.Kpub. (On rappelle que la validité du certificat R.cert contenant la clé publique R.Kpub a été vérifiée à l’étape E10.)
[01 10] En l’absence de vérification (c’est-à-dire en cas d’inégalité à l’étape de comparaison du condensât précité et du résultat précité), il est mis fin au processus d’installation, éventuellement avec envoi d’un message d’erreur à destination du serveur distant S.
[01 1 1 ] En cas de vérification positive à l’étape E14 (c’est-à-dire en cas d’égalité à l’étape de comparaison du condensât précité et du résultat précité), le processus d’installation se poursuit à l’étape E16 décrite à présent.
[01 12] L’unité de traitement 4 distribue à l’étape E16 divers paquets d’équipement ECUPACK aux équipements électroniques chargés de l’installation des composants informatiques, ici par exemple la première unité électronique de commande 6 et/ou la passerelle 8.
[01 13] Chaque paquet d’équipement ECUPACK contient les données du conteneur global GLOB destinées à un équipement électronique particulier (ici première unité électronique de commande 6 ou passerelle 8), c’est-à-dire les données du paquet d’équipement ECUPACKn destiné à cet équipement électronique, avec ou sans les composants informatiques COMP1 , COMP2, COMPi eux même selon le mode de réalisation concerné.
[01 14] Comme déjà indiqué, on peut en effet prévoir que tout ou partie des composants électroniques soit transmis dans le conteneur global GLOB à l’étape E6 et donc que certains paquets d’équipement ECUPACK au moins comprennent un ou plusieurs composant(s) informatique(s).
[01 15] Chaque équipement électronique concerné reçoit ainsi un paquet d’équipement ECUPACK à l’étape E18. On décrit dans la suite la mise en oeuvre du procédé pour un tel équipement électronique (ici première unité électronique de commande 6 ou passerelle 8), des étapes similaires étant toutefois en pratique mises en oeuvre pour les autres équipements électroniques recevant un paquet d’équipement ECUPACK.
[01 16] L’équipement électronique (soit ici la première unité électronique de commande 6 ou la passerelle 8) peut alors éventuellement mettre en oeuvre à l’étape E20 une étape de vérification du certificat constructeur R.cert et du certificat d’autorité CA.cert. On rappelle que dans l’exemple décrit ici, ces certificats R.cert et CA.cert font partie d’un champ de type cms du paquet d’équipement ECUPACK.
[01 17] Les vérifications de l’étape E20 (effectuées par l’équipement électronique 6, 8 concerné) sont similaires à celle réalisées aux étapes E10 et E12 décrites plus haut par l’unité de traitement 4, et ne seront donc pas décrites en détail ici.
[01 18] En l’absence de vérification à l’étape E20, il est mis fin au processus d’installation au sein de l’équipement 6, 8 concerné. Un message d’erreur peut par ailleurs être envoyé à l’unité de traitement 4 (pour transmission éventuelle au serveur distant S, par exemple).
[01 19] En cas de vérification positive à l’étape E20, l’équipement électronique 6, 8 concerné procède à l’étape E22 à la vérification de l’intégrité du manifeste ECUPACKIND (reçu au sein du paquet d’équipement ECUPACKIND).
[0120] Pour ce faire, l’équipement électronique 6, 8 concerné applique un algorithme cryptographique de vérification de signature utilisant la clé publique R.Kpub à la signature SIG(ECUPACKIND) et au manifeste ECUPACKIND. En pratique, on compare par exemple un condensât du manifeste ECUPACKIND et le résultat obtenu par application à la signature SIG(ECUPACKIND) d’un algorithme cryptographique (ici de type RSA) utilisant la clé publique R.Kpub. (On rappelle que la validité du certificat R.cert contenant la clé publique R.Kpub a été vérifiée à l’étape E20.) [0121 ] En l’absence de vérification (c’est-à-dire en cas d’inégalité à l’étape de comparaison du condensât précité et du résultat précité), il est mis fin au processus d’installation au niveau de l’équipement électronique 6, 8 concerné, éventuellement avec envoi d’un message d’erreur à l’unité de traitement 4 (pour transmission éventuelle au serveur distant S, par exemple).
[0122] En cas de vérification positive à l’étape E22 (c’est-à-dire en cas d’égalité à l’étape de comparaison du condensât précité et du résultat précité), l’équipement électronique 6, 8 concerné vérifie à l’étape E24 si l’identifiant VIN du véhicule V inclus dans le manifeste ECUPACKIND correspond (c’est-à-dire en pratique est égal) à l’identifiant VIN du véhicule V mémorisé (par exemple dans une mémoire non-volatile) au sein de l’équipement électronique 6, 8.
[0123] En l’absence de vérification (c’est-à-dire en cas d’inégalité entre l’identifiant VIN indiqué dans le manifeste ECUPACKIND et l’identifiant mémorisé), il est mis fin au processus d’installation au niveau de l’équipement électronique 6, 8 concerné, éventuellement avec envoi d’un message d’erreur à l’unité de traitement 4 (pour transmission éventuelle au serveur distant S, par exemple).
[0124] En cas de vérification positive à l’étape E24 (c’est-à-dire en cas d’égalité entre l’identifiant VIN indiqué dans le manifeste ECUPACKIND et l’identifiant mémorisé), l’installation peut se poursuivre à l’étape E32 décrite plus loin (après réception des composants informatiques comme décrit à présent).
[0125] En parallèle du traitement qui vient d’être mentionné au sein de l’équipement électronique 6, 8 chargé de l’installation, le serveur distant S émet à l’étape E26 au moins un composant informatique COMPi du paquet de téléchargement DPACK, à destination de l’unité de traitement 4. (Bien que cela ne soit pas représenté en figure 4, cette émission du composant informatique COMPi peut être déclenchée suite à la réception par le serveur distant S d’une indication en provenance de l’unité de traitement 4, cette indication signalant par exemple une place suffisante dans la mémoire tampon pour mémorisation du composant informatique COMPi.)
[0126] L’unité de traitement 4 reçoit le composant informatique COMPi à l’étape E28.
[0127] On décrit dans la suite le traitement d’un seul composant informatique COMPi. En pratique, plusieurs composants informatiques sont reçus, au même instant ou à un instant ultérieur en fonction des capacités de la mémoire tampon de l’unité de traitement 4, et sont traités comme décrit pour le composant informatique COMPi.
[0128] Lorsque le composant COMPi reçu à l’étape E28 permet de compléter (en utilisant des données du conteneur global GLOB) un paquet d’équipement ECUPACKn, l’unité de traitement 4 peut éventuellement mettre en oeuvre à l’étape E29 une vérification du contenu du paquet d’équipement ECUPACKn concerné, en comparant par exemple le condensât H(ECUPACKn) contenu dans le manifeste DPACKIND et un condensât obtenu par application de la fonction de hachage (ici SHA256) au paquet d’équipement ECUPACKn tel que reçu.
[0129] En l’absence de vérification (c’est-à-dire si le condensât H(ECUPACKn) du manifeste DPACKIND diffère du condensât obtenu sur la base du paquet d’équipement ECUPACKn reçu), le composant informatique COMPi n’est pas communiqué à l’équipement électronique 6, 8 concerné et un message d’erreur peut éventuellement être envoyé au serveur distant S.
[0130] En cas de vérification positive à l’étape E29 (c’est-à-dire en cas d’égalité entre le condensât H(ECUPACKn) du manifeste DPACKIND et le condensât obtenu sur la base du paquet d’équipement ECUPACKn reçu), le composant informatique COMPi est distribué à l’équipement électronique 6, 8 concerné à l’étape E30.
[0131 ] L’équipement électronique 6, 8 concerné reçoit ainsi le composant informatique COMPi à l’étape E32.
[0132] L’équipement électronique 6, 8 peut alors vérifier ce composant informatique COMPi.
[0133] Tout d’abord, à l’étape E34, l’équipement électronique 6, 8 compare le condensât H(COMPi) contenu dans le manifeste ECUPACKIND et un condensât obtenu par application de la fonction de hachage (ici SHA256) au composant informatique COMPi reçu. (On rappelle que l’intégrité du manifeste ECUPACKIND a été vérifiée à l’étape E22.)
[0134] En cas de vérification négative (c’est-à-dire si le condensât H(COMPi) contenu dans le manifeste ECUPACKIND diffère du condensât obtenu), il est mis fin à l’installation du composant informatique COMPi.
[0135] En cas de vérification positive à l’étape E34 (c’est-à-dire en cas d’égalité entre le condensât H(COMPi) contenu dans le manifeste ECUPACKIND et le condensât obtenu), la vérification du composant informatique COMPi se poursuit à l’étape E36. [0136] L’équipement électronique 6, 8 vérifie tout d’abord à l’étape E36 l’intégrité du manifeste COMPIND du composant informatique COMPi.
[0137] Pour ce faire, l’équipement électronique 6, 8 concerné applique un algorithme cryptographique de vérification de signature utilisant la clé publique BK.Kpub à la signature SIG(COMPIND) et au manifeste COMPIND. En pratique, on compare par exemple un condensât du manifeste COMPIND et le résultat obtenu par application à la signature SIG(COMPIND) d’un algorithme cryptographique (ici de type RSA) utilisant la clé publique BK.Kpub.
[0138] La clé publique BK.Kpub est par exemple mémorisée dans une mémoire non-volatile de l’équipement électronique 6, 8 concerné.
[0139] En l’absence de vérification (c’est-à-dire en cas d’inégalité à l’étape de comparaison du condensât précité et du résultat précité), il est mis fin au processus d’installation du composant informatique COMPi, éventuellement avec envoi d’un message d’erreur à l’unité de traitement 4 (pour transmission éventuelle au serveur distant S, par exemple).
[0140] En cas de vérification positive de la signature SIG(COMPIND) (c’est-à-dire en cas d’égalité à l’étape de comparaison du condensât précité et du résultat précité), l’équipement électronique 6, 8 compare le condensât H(CONTEN) contenu dans le manifeste COMPIND et un condensât obtenu par application de la fonction de hachage (ici SHA256) au contenu CONTEN du composant informatique COMPi reçu.
[0141 ] En l’absence de vérification (c’est-à-dire en cas d’inégalité entre le condensât H(CONTEN) du manifeste COMPIND et le condensât obtenu), il est mis fin au processus d’installation du composant informatique COMPi, éventuellement avec envoi d’un message d’erreur à l’unité de traitement 4 (pour transmission éventuelle au serveur distant S, par exemple).
[0142] En cas de vérification positive (c’est-à-dire en cas d’égalité entre le condensât H(CONTEN) du manifeste COMPIND et le condensât obtenu), le procédé d’installation se poursuit comme décrit à présent.
[0143] Dans le cas par exemple où le véhicule V est un véhicule à moteur thermique, on peut alors prévoir une étape E38 d’attente de mise en fonctionnement du moteur thermique (ce qui permet en pratique de s’assurer que tous les équipements électroniques sont en fonctionnement et que le composant informatique COMPi pourra être correctement installé dans l’équipement électronique concerné).
[0144] Lorsque le moteur thermique est en fonctionnement (ou sans cette condition pour un véhicule sans moteur thermique), l’équipement électronique 6, 8 concerné commande l’installation du composant informatique COMPi, c’est-à-dire la mémorisation du composant informatique COMPi dans une mémoire non-volatile (réinscriptible) en vue de son utilisation ultérieure.
[0145] Dans certains cas (par exemple pour la première unité électronique de commande 6), l’installation du composant informatique COMPi est effectuée au sein même de l’équipement électronique (ici la première unité électronique de commande 6) qui a mis en œuvre les étapes préalables de vérification E20 à E36 décrites ci-dessus.
[0146] Dans d’autres cas en revanche (ici pour la passerelle 8), l’équipement électronique (ici la passerelle 8) chargé de l’installation, et ayant dans ce cadre effectué les étapes préalables de vérification E20 à E36, commande l’installation du composant informatique COMPi au sein d’un autre équipement électronique, ici la seconde unité électronique de commande 10. La passerelle 8 commande ainsi par exemple la mémorisation du composant informatique COMPi dans une mémoire non-volatile (réinscriptible) de la seconde unité électronique de commande 10.
[0147] On prévoit ici de ne pas utiliser les composants informatiques dès leur installation, mais lorsque d’autres conditions sont remplies comme décrit à présent.
[0148] Lorsque le véhicule V est un véhicule à moteur thermique, on peut utiliser une étape E42 d’attente de l’arrêt du fonctionnement du moteur thermique.
[0149] Lorsque le moteur thermique du véhicule V est à l’arrêt (ou que le véhicule V n’utilise aucun moteur thermique), l’unité de traitement 4 affiche sur une interface utilisateur (par exemple un écran disposé dans l’habitacle du véhicule V) une indication que des composants informatiques ont été installés et sont prêts à être utilisés (étape E44).
[0150] L’unité de traitement 4 attend alors à l’étape E46 une réponse de l’utilisateur (par exemple le conducteur du véhicule V), par exemple via l’interface utilisateur précitée (éventuellement l’écran susmentionné lorsque cet écran est tactile).
[0151 ] En cas de réponse négative de l’utilisateur, le(s) composant(s) informatique(s) installé(s) à l’étape E40 n’est (ne sont) pas utilisé(s).
[0152] En cas de réponse positive de l’utilisateur à l’étape E46, l’unité de traitement 4 émet, à destination des différents équipements électroniques concernés (ici la première unité électronique de commande 6 et, via la passerelle 8, la seconde unité électronique de commande 10), une commande CMD d’activation des composants informatiques installés (étape E48).
[0153] Les composants informatiques installés sont alors activés (étape E50).
[0154] Pour les composants informatiques logiciels, des instructions comprises dans le composant informatique concerné peuvent alors être exécutées par le processeur de l’équipement électronique 6, 10 dans lequel le composant informatique a été installé.
[0155] Pour les composants informatiques formés de données manipulables, des données comprises dans le composant informatique concerné peuvent être manipulées par le processeur de l’équipement électronique 6, 10 dans lequel le composant informatique a été installé.

Claims

REVENDICATIONS
1. Procédé d’installation d’un composant informatique (COMP1 ) dans un équipement électronique (6 ; 10) équipant un véhicule (V), comprenant des étapes consistant à :
- recevoir (E18) un paquet d’équipement (ECUPACK) comprenant un premier manifeste (ECUPACKIND) incluant un condensât (H(COMP1 )) du composant informatique ;
- vérifier (E22) l’intégrité du premier manifeste (ECUPACKIND) ;
- recevoir (E32) le composant informatique (COMP1 ) ;
- vérifier (E34) la correspondance entre le condensât (H(COMP1 )) du composant informatique et le composant informatique (COMP1 ) reçu ;
- installer (E40) le composant informatique (COMP1 ) seulement en cas de vérification positive de l’intégrité du premier manifeste (ECUPACKIND), et de vérification positive de la correspondance.
2. Procédé selon la revendication 1 , dans lequel le premier manifeste
(ECUPACKIND) inclut un premier identifiant (VIN) de véhicule, et comprenant des étapes consistant à :
- comparer (E24) le premier identifiant (VIN) de véhicule à un second identifiant de véhicule mémorisé au sein du véhicule (V) ;
- installer (E40) le composant informatique (COMP1 ) seulement en cas de comparaison positive du premier identifiant (VIN) et du second identifiant.
3. Procédé selon la revendication 1 ou 2, dans lequel le paquet d’équipement
(ECUPACK) comprend une première signature (SIG(ECUPACKIND)) et dans lequel l’intégrité du manifeste (ECUPACKIND) est vérifiée en appliquant un algorithme cryptographique de vérification de signature à la première signature
(SIG(ECUPACKIND)) et au premier manifeste (ECUPACKIND).
4. Procédé selon l’une des revendications 1 à 3, dans lequel le composant informatique (COMP1 ) est reçu indépendamment du paquet d’équipement (ECUPACK).
5. Procédé selon la revendication 1 à 3, dans lequel le composant informatique
(COMP1 ) est reçu au sein du paquet d’équipement (ECUPACK).
6. Procédé selon l’une des revendications 1 à 5, comprenant des étapes consistant à :
- recevoir (E8) un conteneur (GLOB) comprenant ledit paquet d’équipement (ECUPACK) et un deuxième manifeste (DPACKIND) ;
- vérifier (E14) l’intégrité du deuxième manifeste (DPACKIND).
7. Procédé selon la revendication 6, dans lequel le conteneur (GLOB) comprend un autre paquet d’équipement (ECUPACK2) destiné à un autre équipement électronique.
8. Procédé selon l’une des revendications 6 ou 7, dans lequel le deuxième manifeste (DPACKIND) inclut un premier identifiant (VIN) de véhicule, et comprenant des étapes consistant à :
- comparer (E12) le premier identifiant (VIN) de véhicule à un second identifiant de véhicule mémorisé au sein du véhicule (V) ;
- transmettre (E16) ledit paquet d’équipement (ECUPACK) seulement en cas de comparaison positive du premier identifiant (VIN) et du second identifiant.
9. Procédé selon l’une des revendications 6 à 8, dans lequel le conteneur (GLOB) est reçu en provenance d’un serveur distant (S) en réponse à une requête (REQ) émise par le véhicule (V).
10. Procédé selon l’une des revendications 6 à 8, dans lequel le conteneur (GLOB) est reçu d’une carte mémoire (20) insérée dans un lecteur (12) équipant le véhicule (V).
1 1 . Procédé selon l’une des revendications 1 à 10, dans lequel le composant informatique (COMP1 ) comprend une seconde signature (SIG(COMPIND)) et un contenu (CONTEN), et dans lequel le procédé comprend une étape (E36) de vérification de l’intégrité du contenu (CONTEN) au moyen de la seconde signature (SIG(COMPIND)).
12. Equipement électronique (6 ; 8) destiné à équiper un véhicule et comprenant:
- un module de réception d’un paquet d’équipement (ECUPACK) comprenant un manifeste (ECUPACKIND) incluant un condensât (H(COMPi)) d’un composant informatique ;
- un module de vérification de l’intégrité du manifeste (ECUPACKIND) ;
- un module de réception du composant informatique (COMPi) ;
- un module de vérification de la correspondance entre le condensât (H(COMPi)) du composant informatique et le composant informatique (COMPi) reçu ;
- un module d’installation conçu pour installer le composant informatique (COMPi) seulement en cas de vérification positive de l’intégrité du manifeste (ECUPACKIND) et de vérification positive de la correspondance.
13. Equipement électronique (6 ; 8) selon la revendication 12, dans lequel le manifeste (ECUPACKIND) inclut un premier identifiant (VIN) de véhicule et comprenant:
- un module de comparaison du premier identifiant (VIN) de véhicule et d’un second identifiant du véhicule (V) mémorisé au sein du véhicule (V), dans lequel le module d’installation est conçu pour installer le composant informatique (COMPi) seulement en cas de vérification positive de l’intégrité du manifeste (ECUPACKIND), de comparaison positive du premier identifiant (VIN) et du second identifiant, et de vérification positive de la correspondance.
EP20717217.2A 2019-05-16 2020-04-15 Procede d'installation d'un composant informatique et equipement electronique associe Pending EP3970315A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1905119A FR3096160B1 (fr) 2019-05-16 2019-05-16 Procédé d’installation d’un composant informatique et équipement électronique associé
PCT/EP2020/060506 WO2020229074A1 (fr) 2019-05-16 2020-04-15 Procede d'installation d'un composant informatique et equipement electronique associe

Publications (1)

Publication Number Publication Date
EP3970315A1 true EP3970315A1 (fr) 2022-03-23

Family

ID=67875656

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20717217.2A Pending EP3970315A1 (fr) 2019-05-16 2020-04-15 Procede d'installation d'un composant informatique et equipement electronique associe

Country Status (7)

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

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130111212A1 (en) * 2011-10-28 2013-05-02 GM Global Technology Operations LLC Methods to provide digital signature to secure flash programming function
US9722781B2 (en) * 2014-07-09 2017-08-01 Livio, Inc. Vehicle software update verification
US9916151B2 (en) * 2015-08-25 2018-03-13 Ford Global Technologies, Llc Multiple-stage secure vehicle software updating
GB2541950B (en) * 2015-09-07 2020-01-08 Arm Ip Ltd Methods for verifying data integrity

Also Published As

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

Similar Documents

Publication Publication Date Title
US8972736B2 (en) Fully authenticated content transmission from a provider to a recipient device via an intermediary device
US8327146B2 (en) Wireless communication using compact certificates
US8731155B2 (en) Method for remotely controlling vehicle features
EP3297247A1 (fr) Mise en réseau cryptè dans un véhicule
US20110320089A1 (en) Over-the-Air Vehicle Systems Updating and Associate Security Protocols
EP3269108A1 (fr) Procédé de transmission sécurisée d'une clé virtuelle et méthode d'authentification d'un terminal mobile
EP1605668B1 (fr) Procédé de chargement de fichiers depuis un client vers un serveur cible et dispositif pour la mise en oeuvre du procédé
US9209977B2 (en) Processing messages received at a vehicle
US20100202616A1 (en) Method of securing and authenticating data using micro-certificates
US20110225259A1 (en) System and method for communicating software applications to a motor vehicle
KR102450811B1 (ko) 차량 내부 네트워크의 키 관리 시스템
EP1756696B1 (fr) Methode de mise a jour securisee de logiciel embarque dans un module de securite
WO2020229074A1 (fr) Procede d'installation d'un composant informatique et equipement electronique associe
Chawan et al. Security enhancement of over-the-air update for connected vehicles
CN115038064A (zh) 一种车辆信号处理方法
WO2021023694A1 (fr) Procédé d'écriture dans une zone de données sécurisée d'un calculateur sur bus embarqué de véhicule
WO2022042981A1 (fr) Procédé pour une modification logicielle dans un véhicule automobile
Nikhil et al. Generation of flash containers in PDX format for automotive secure gateway
RU2812276C2 (ru) Способ установки вычислительного компонента и сопутствующее электронное устройство
CN115208694B (zh) 基于中央计算平台的车载网络通信加密***及车辆
EP3987741A1 (fr) Support mémoire, procédé d'installation de composants informatiques au sein d'un vehicule et procédé de préparation d'un support mémoire
FR3006836A1 (fr) Procede de telechargement d'un certificat pseudonyme delivre par une infrastructure a cle publique pour un vehicule automobile et vehicule automobile utilisant un tel procede
FR3075536A1 (fr) Procede d'authentification d'un dispositif electronique par une unite electronique equipant un vehicule
FR3119906A1 (fr) Procédé de vérification de l’authenticité d’une commande d’un actionneur
EP3259159B1 (fr) Procédé de mise en oeuvre d'une connexion entre un dispositif électronique esclave et un dispositif électronique maître, et dispositif électronique esclave associé

Legal Events

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

Free format text: STATUS: UNKNOWN

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

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

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

Free format text: ORIGINAL CODE: 0009012

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20211104

AK Designated contracting states

Kind code of ref document: A1

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

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

Owner name: NISSAN MOTOR CO., LTD.

Owner name: RENAULT S.A.S

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

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

Owner name: NISSAN MOTOR CO., LTD.

Owner name: AMPERE SAS

17Q First examination report despatched

Effective date: 20240314