Patent Application
20240028731
The present invention relates to a method for bringing about a software modification in a motor vehicle, to an automotive computer, to a computer program product for implementing the method and to a removable storage medium.
Current motor vehicles comprise a high number of detectors, of devices and/or of systems that are capable of assisting a driver in his driving tasks, for example when an autonomous or semi-autonomous vehicle is being driven. Such detectors are, for example, one or more cameras, infrared detectors, radio-frequency detectors, a LIDAR system (LIDAR being the acronym of LIght Detection and Ranging), etc. These detectors are placed inside the vehicle and/or outside it. In order to exploit these various sensors, the motor vehicle incorporates in its computers a number of pieces of firmware or embedded software. This embedded software allows the computer to change, for example so as to incorporate new functionalities, without there being any need to completely revise the design of said computer. It is thus sometimes necessary to update this embedded software or to incorporate new software into the motor vehicle. Document WO2019126525 discloses a method for updating software within a motor vehicle. In this method, the data to be updated are encrypted using a specific key and then transmitted to the motor vehicle. The transmitted data are then decrypted in said motor vehicle via a private key. Although this method allows embedded software to be updated securely, the motor vehicle on the whole remains passive with respect to this update.
Specifically, it is not possible for it to refuse the update, for example if the update is incompatible with specific characteristics of the motor vehicle or if the update does not correspond to a predefined update context (update location, update period, update instigator (engineer, factory, dealership, end customer)). Specifically, in the context of an update of embedded software in a motor vehicle, two supervisory authorities are generally involved. The first supervisory authority, called the primary supervisory authority, is the one that provides the software data to be updated—it is typically the manufacturer of the motor vehicle. This primary supervisory authority defines the security and applicability policies that must be respected. These policies must be easily configurable by a second supervisory authority, called the secondary supervisory authority, which is responsible for deploying updates. The operational constraint is that the primary supervisory authority which generates the software data and the secondary supervisory authority in charge of deploying these software data are not physically the same. Thus, attackers (in the cyber-security sense) could modify the content of the software data or the deployment properties of these contents, and this could trigger problems with execution of the software data thus modified in the motor vehicle.
There is therefore a need to improve the security of modification of embedded software in motor vehicles, in particular when the context of this modification comprises a certain number of restrictions such as space or time restrictions.
The present invention aims to at least partially meet this need.
More particularly, the present invention aims to increase the security of software updates in a motor vehicle, in particular when a plurality of entities are responsible for implementing these updates.
A first subject of the invention relates to a method for bringing about a software modification in a motor vehicle, said method comprising the following steps:
The invention makes it possible to create a two-level signature by separating the roles of the different primary and secondary supervisory authorities. The primary supervisory authority is thus responsible for digital signature of the software data. This primary authority also generates general deployment data, which are also referred to as deployment permissions. The secondary supervisory authority for its part manages actual deployment of the software data. This secondary supervisory authority is in charge of providing the actual deployment policies and of signing them digitally. It thus adds information for which it is responsible, and which supplements the deployment permissions of the primary supervisory authority. The automotive computer will then verify that the digital signatures and also the actual deployment policies comply with the deployment permissions and the specific characteristics of the motor vehicle. Thus, the invention allows a cryptographic separation of privileges upstream between the primary supervisory authority and the secondary supervisory authority. It also allows verification to be performed downstream in the computer implementing the software modification. This method further permits a high degree of flexibility in said software modification. Specifically, the deployment permissions are set in an intangible way by the primary supervisory authority. The specific deployment data may for their part be adapted by the secondary supervisory authority, for example, in the event of return of a software fault in a given vehicle range, it is the vehicles of this range that will be specifically targeted by a software modification.
In one particular embodiment, the general deployment data of the software comprise at least one of the following criteria for deployment of the software:
Use of all or some of these general criteria allows deployment permissions defining a fairly broad software-deployment framework to be generated.
In one particular embodiment, the specific deployment data of the software comprise at least one of the following criteria:
Use of all or some of these specific criteria allows actual deployment permissions defining a fairly precise software-deployment framework to be generated.
In one particular embodiment, the general space criterion defines the possible locations in which software deployment may be carried out, such as in a factory, at a dealership, or at an individual's home, and the specific space criterion is a choice among these various locations.
In one particular embodiment, the general time criterion defines the time ranges in which software deployment may be carried out, and the specific space criterion is a choice among these various time ranges.
In one particular embodiment, the general identification criterion defines a type of identifier, such as a vehicle identification number, and the specific identification criterion is a choice of a group of identifiers for this type of identifier.
The type of identification used is for example a VIN code (VIN being the acronym of Vehicle Identification Number). The VIN code is a unique alphanumeric code that is given to each and every vehicle. This code is standardized and has 17 characters. It is present at least twice on a vehicle, for example on part of the chassis of the vehicle or on the manufacturer's plate. It is also integrated into its automotive computer and it is one of the specific characteristics of the motor vehicle.
In one particular embodiment, the general software-deployment data comprise a digital fingerprint of the software data, said digital fingerprint having been obtained by a hash function, and this digital fingerprint is compared with a digital fingerprint generated in the motor vehicle from the software data with a view to implementing the software-modifying step.
The hash function used is for example an SHA or MD5 cryptographic function (SHA being the acronym of Secure Hash Algorithm and MD5 the acronym of Message Digest 5). These are functions that, for an input dataset, will generate a unique digital fingerprint. So for two different input datasets, two different digital fingerprints would be generated by the hash function. Therefore any alteration of the input data leads to generation of a different digital fingerprint by the hash function. Thus, it is sufficient to verify the integrity of the digital fingerprint to assess whether or not the software data have been modified maliciously. It is not necessary to verify the integrity of all the software data. The data processing required to achieve the software modification in the motor vehicle is thus facilitated.
In one particular embodiment, the general software-deployment data are signed with a first private key and said signature is verified with a first public key associated with said first private key. The specific software-deployment data are signed with a second private key and said signature is verified with a second public key associated with said second private key.
The first private key is held by the primary supervisory authority. The second private key is held by the secondary supervisory authority. The first public key and the second public key are placed in the computer of the motor vehicle during manufacture of said motor vehicle. Through use of asymmetric cryptography, it is possible to ensure secure transmission of data between, on the one hand, the primary supervisory authority and secondary supervisory authority, and on the other hand, the motor vehicle. Furthermore, even should the first public key and the second public key be cracked by a malicious participant, the latter would be unable to determine the first private key and the second private key held by the primary supervisory authority and by the secondary supervisory authority, respectively.
In one particular embodiment, the software modification is introduction of new software and/or update of software already installed in said vehicle.
In one particular embodiment, the first data group and the second data group are received by connecting, to said motor vehicle, a removable storage medium such as a USB key, and the specific deployment data of the software comprise at least one criterion related to said removable storage medium.
Use of a removable storage medium allows a greater amount of data to be securely transmitted than is possible with the wireless technology called firmware over-the-air (FOTA). Furthermore, it is not necessary for the motor vehicle to be a so-called connected vehicle for software updates to be possible. Lastly, use of a removable storage medium makes it possible to avoid malicious DDoS attacks (DDoS being the acronym of Distributed Denial of Service).
Another subject of the invention relates to an automotive computer comprising means for receiving a first data group and a second data group. Said first data group comprises software data and general software-deployment data, said general software-deployment data having been signed by a primary supervisory authority. Said second data group comprises specific software-deployment data, said specific software-deployment data having been signed by a secondary supervisory authority. The computer comprises means for verifying the signature of the specific software-deployment data. Since the motor vehicle has specific characteristics, the computer comprises means for verifying the compatibility of the specific software-deployment data with said specific characteristics of the motor vehicle. The computer comprises means for verifying the signature of the general software-deployment data, means for verifying the compatibility of the specific software-deployment data with the general software-deployment data, and means for modifying software in the motor vehicle via the data software of the first data group.
Another object of the invention relates to a computer program product comprising program instructions that are exploitable by the above automotive computer, which, when they are executed or interpreted by said computer, trigger implementation of the above method for bringing about a software modification in a motor vehicle.
Another subject of the invention relates to a removable storage medium comprising means for storing a first data group and a second data group, said first data group comprising software data and general software-deployment data, said general software-deployment data having been signed by a primary supervisory authority, said second data group comprising specific software-deployment data, said specific software-deployment data having been signed by a secondary supervisory authority. The storage medium comprises means for transferring the first data group and the second data group to the motor vehicle, the signature of the specific software-deployment data being intended to be verified in said motor vehicle in a first verifying step, the specific deployment data of the software being intended to be verified in order to assess their compatibility with specific characteristics of the motor vehicle in a second verifying step, the signature of the general software-deployment data being intended to be verified in said motor vehicle in a third verifying step, the specific software-deployment data and the general software-deployment data being intended to be verified in order to assess their compatibility in a fourth verifying step. The software data of the first data group are intended to perform a software modification in the motor vehicle if the first verifying step, the second verifying step, the third verifying step and the fourth verifying step are validated.
The present invention will be better understood on reading the detailed description of embodiments, which are given by way of completely non-limiting example, and illustrated by the appended drawings, in which:
The invention is not limited to the embodiments and variants described and other embodiments and variants will appear obvious to those skilled in the art.
In the various figures, identical or similar elements have been designated by the same references.
The means 111 for receiving data are able to receive a first data group. The first data group comprises: software data BIN, a digital fingerprint Enum of the software data, and general software-deployment data DGD. The software data BIN correspond to the code lines for updating the existing firmware and/or to the new firmware to be installed in the motor vehicle. The digital fingerprint Enum corresponds to the result of a hash function applied to the software data BIN.
The general software-deployment data DGD comprise at least one of the following criteria for software deployment:
The general space criterion CGE defines the possible locations in which software deployment may be carried out, such as in a factory, at a dealership, or at an individual's home.
The general time criterion CGT defines the time ranges in which software deployment may be carried out.
The general identification criterion CGI defines a type of identifier on which software deployment may be based. In one particular embodiment, this type of identifier is the VIN code of the motor vehicle or part of this VIN code.
The general software-deployment data DGD are able to be signed by a primary supervisory authority 32 (see
The means 111 for receiving data are also able to receive a second data group. The second data group comprises: specific software-deployment data DSD.
The specific software-deployment data DSD comprise at least one of the following criteria:
The specific space criterion CSE for software deployment is one or more choices among the various locations of the general space criterion CGE of the first data group.
The specific time criterion CST for software deployment is one or more choices among the various time ranges of the general time criterion CGT of the first data group.
The specific identification criterion CSI for identifying identification vehicles is a choice of a group of identifiers for the type of identifier of the general identification criterion CGI of the first data group.
The specific software-deployment data DSD are able to be signed by a secondary supervisory authority 34 (see
The first verifying means 112 are able to verify the data signature of the second data group.
The second verifying means 113 are able to verify the compatibility of the specific deployment data DSD with the specific characteristics CP of the motor vehicle. These specific characteristics for example comprise the particular VIN code of the motor vehicle.
The third verifying means 114 are able to verify the data signature of the first data group.
The fourth verifying means 115 are able to verify the compatibility of the specific software-deployment data DSD with the general software-deployment data DGD.
The software-modifying means 116 are able to add one or more pieces of firmware and/or to update one or more pieces of firmware using the software data BIN of the first data group.
In one non-limiting example of operation, which is illustrated in
The database 31 is able to store a first data group. As already indicated, this first data group comprises software data BIN and general deployment data DGD (CGE, CGT, CGI). The software data BIN will have been generated beforehand by a supplier of the software in question. The data DGD (CGE, CGT, CGI) will have been generated beforehand and signed by a primary supervisory authority 32. This signature is made using the first private key 321. This primary supervisory authority 32 is managed by a main security officer and a firmware manager (not shown in
It will be noted that some permissions are a combination of a general identification/location/time criterion with a specific identification/location/time criterion, such as:
The server 35 is able to interrogate the database 31 in order to associate the data of the first data group BIN, DGD (CGE, CGT, CGI), ENum with data of a second data group DSD (CSE, CST, CSI) in a single database 36. The data of the second data group DSD (CSE, CST, CSI) are generated on the fly based on a request REQ originating from the generating means 37. These data DSD (CSE, CST, CSI) are signed using the second private key 341.
It is the entity in charge of the software deployment (not shown in
It is this entity in charge of the software deployment that is able to define the actual deployment policies. More particularly, in the case where deployment is via a removable storage medium, such as a USB key 38, the actual deployment policies may be, by way of example and non-exhaustively:
The generating means 37 are able to generate the request REQ and address it to the server 35, with a view to a software modification. This request is generated on the initiative of a user, such as a research department 371 of the manufacturer, a factory 372 of the manufacturer, a dealership 373, or the customer 374 who bought the motor vehicle 10. The request REQ is, for example, a request according to the HTTP Internet protocol (HTTP being the acronym of HyperText Transfer Protocol). In response, the generating means 37 transmit the first data group BIN, DGD (CGE, CGT, CGI), ENum and the second data group DSD (CSE, CST, CSI) on the software update request. In one particular embodiment, the request REQ comprises a secret code obtained beforehand by the user in order to secure the transfer of the first data group and of the second data group from the server 35 to the generating means 37.
The first data group and the second data group are then stored on the USB key 38. This USB key 38 is, for example, any commercially available key. As a variant, the USB key 38 is dedicated to software-modification operations. This USB key 38 was for example provided beforehand by the manufacturer of the motor vehicle 10.
The USB key 38 thus comprises means for storing the first data group and the second data group. The USB key 38 also comprises means for transferring this first data group BIN, DGD (CGE, CGT, CGI), ENum and this second data group DSD (CSE, CST, CSI) to the computer 11 of the motor vehicle 10. As was mentioned above, this computer 11 comprises the first public key 1141 complementary to the first private key 321, and the second public key 1121 complementary to the second private key 341.
The computer 11 thus allows the method for bringing about the software modification in the motor vehicle 10 to be implemented. The steps of this method are in particular illustrated in
Thus, considering examples permission 1 to permission 6 and examples policy 1 and policy 2 of the preceding paragraphs, the computer 11 will verify overall consistency, namely:
The invention thus makes it possible to supplement, with appropriate deployment policies, the deployment permissions generated by the primary supervisory authority. Furthermore, the entity in charge of software deployment may specify a deployment policy while ensuring that it is compatible with the deployment permissions imposed by the primary supervisory authority.
The computer 11 is then responsible for verifying consistency between the deployment policies of the software data and the deployment permissions of these software data. The computer 11 will permit installation of a new piece of software or permit software to be updated only if the deployment policy of this software or update is permitted by the deployment permissions.
In one preferred embodiment, the computer 11 generates a digital fingerprint from the software data BIN. This generated digital fingerprint is compared to the digital fingerprint ENum of the software data of the first data group. In the case where the digital fingerprints are identical, the software modification is permitted. Otherwise, the software modification is cancelled.
The invention also relates to a computer program product comprising program instructions that are exploitable by the automotive computer 11. These instructions, when they are executed or interpreted by the computer 11, trigger implementation of the method for bringing about the software modification in the motor vehicle 10.
The invention is not limited to the embodiments and variants described and other embodiments and variants will appear obvious to those skilled in the art.
Thus, the general software-deployment data DGD and the digital fingerprint Enum are signed by two different private keys to improve the overall level of cyber-protection against hacking.
Thus, the research department 371 of the manufacturer or the factory 372 of the manufacturer or the dealership 373 uses a defined pair of private/public keys to obtain the first data group and the second data group in a secure manner. These data are intended to be loaded onto the USB key 38.
Thus, the first data group and the second data group may be transferred between the server 35 and the motor vehicle 10 via FOTA wireless technology.
Thus, software may be updated a plurality times during use of the motor vehicle. It is then possible to implement new hashing techniques during these updates.
| Number | Date | Country | Kind |
|---|---|---|---|
| 20 08706 | Aug 2020 | FR | national |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2021/071041 | 7/27/2021 | WO |
