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)
• Storage Device Security (AREA)
• Stored Programmes (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=67875656

Family Applications (1)

Country Status (7)

Family Cites Families (5)

• 2019
  • 2019-05-16 FR FR1905119A patent/FR3096160B1/fr active Active
• 2020
  • 2020-04-15 WO PCT/EP2020/060506 patent/WO2020229074A1/fr active Application Filing
  • 2020-04-15 KR KR1020217041238A patent/KR20220007740A/ko unknown
  • 2020-04-15 CN CN202080035832.0A patent/CN113841358A/zh active Pending
  • 2020-04-15 US US17/610,888 patent/US20220303139A1/en active Pending
  • 2020-04-15 EP EP20717217.2A patent/EP3970315A1/fr active Pending
  • 2020-04-15 JP JP2021568090A patent/JP2022533105A/ja active Pending

Also Published As

Similar Documents

Legal Events