Method for securing vehicle components and corresponding vehicle components

Description

[0001] The present invention relates to a method for securing vehicle components. Furthermore, the invention relates to a vehicle component that carries out such a method and to a motor vehicle that is configured to carry out such a method or has several such vehicle components.

[0002] In the automotive sector, there is a significant need to effectively protect electronic vehicle components and control units against tampering and theft. It is currently estimated that one in three used cars in Germany has a tampered mileage, and the odometer, which displays the mileage and is usually combined with the speedometer or integrated into the instrument cluster, displays an undervalued mileage.

[0003] This can be achieved through odometer manipulation, in which a manipulation device is connected to the vehicle's on-board diagnostics (OBD) port and the previous mileage is overwritten. Such manipulation is easily accomplished because it doesn't require the removal of any components. Furthermore, such manipulation is often difficult to detect. Likewise, a vehicle can display an incorrect mileage if the vehicle component comprising the odometer, originally installed during production, is replaced with a corresponding vehicle component, legally or illegally acquired.

[0004] To prevent or at least make odometer manipulation more difficult, modern vehicles often store the mileage redundantly in multiple control units. If the mileage is then overwritten in only one of the control units, for example, tampering can be detected by comparing the stored mileage readings.

[0005] Furthermore, there are considerations to use blockchain technology to combat odometer manipulation. This involves regularly transmitting the mileage readings of a large number of vehicles to external servers for storage in a public blockchain database. Approaches for this are described in DE 10 2016 007 472 A1 and DE 10 2016 215 914 A1.

[0006] Likewise, the use of stolen, counterfeit, or unauthorized components for various vehicle components is to be made unattractive through so-called component protection. This means that a vehicle component can either not be put into operation or its functionality can at least be restricted if it is installed in a vehicle other than the original one. Various methods are known for detecting whether the affected vehicle component is installed in a different vehicle than the one previously installed.

[0007] In a decentralized implementation, a unique identifier is generated for each vehicle component to be protected through parameterization during vehicle production or upon initial startup. These identifiers are sent or received by the vehicle components to be protected on the vehicle bus each time the vehicle is started. The respective vehicle component stores the identifiers of the other vehicle components to be protected installed in the same vehicle in an untrained state, i.e. during initial operation or after a reset by an authorized body. Upon subsequent restart in the trained state, these then compare the identifiers of the vehicle components to be protected now detected in the vehicle with the stored identifiers. If a vehicle component detects deviations above a certain threshold, e.g.If there is more than one different vehicle component to be protected, the system assumes that it is installed in another vehicle and takes appropriate measures.

[0008] With a central implementation, a key A is stored for each vehicle component to be protected and a matching key B is stored in the vehicle component to be protected through parameterization in a central control unit, for example a gateway that coordinates data transfer within the vehicle's network system. The central control unit and the vehicle components to be protected can then communicate with each other using suitable cryptographic procedures to determine whether the expected matching key is stored in the counterpart. In this way, the vehicle components to be protected can determine whether they are installed in the vehicle for which they were configured. The central control unit can also determine whether all vehicle components to be protected are still installed in the vehicle.

[0009] DE 10 2008 004 808 A1 describes a method for operating an electronic maintenance log for a vehicle, in which performed maintenance work is linked to vehicle data and stored in a memory located in the vehicle. Provision can be made for the information content of the electronic maintenance log stored in the memory to be stored in another memory in the vehicle as a copy or in parts in several other memories in the vehicle. Information concerning spare parts can also be transferred to the electronic maintenance log via a service computer external to the vehicle, where it is linked to vehicle data and stored in the electronic maintenance log.

[0010] It is an object of the invention to provide an improved method for protecting vehicle components against tampering and theft and a corresponding vehicle component.

[0011] This object is achieved by a method having the features of claim 1 and by a corresponding vehicle component according to claim 7. Preferred embodiments of the invention are the subject of the dependent claims.

[0012] The method according to the invention for securing vehicle components comprises the following steps: Capturing vehicle usage data by a first of a plurality of vehicle components; adding a block containing further vehicle usage data to a data structure stored in the first vehicle component, which contains a list of captured vehicle usage data, the captured data being stored in blocks that are linked to one another, each block containing a cryptographic checksum of the previous block, the block being added by this first vehicle component, the added block containing a cryptographic checksum of the most recent block of the data structure; transmitting the new block to at least one of the other vehicle components;and checking the validity of the added block using the cryptographic checksum it contains and a version of the data structure present locally in the at least one other vehicle component, wherein if the result of the check is positive, the added data structure is stored in the at least one other vehicle component and if the result of the check is negative, the range of functions of the first vehicle component is restricted or it cannot be put into operation in the vehicle. ;

[0013] On the one hand, the distributed storage of vehicle usage data across multiple vehicle components allows for the protection of information vulnerable to manipulation, such as mileage readings. On the other hand, component protection can be achieved using the same process. In this way, measures to prevent data manipulation and to protect components can be implemented in a single process. Furthermore, time can be saved in vehicle production compared to conventional component protection methods, as the generation and integration of vehicle- and control unit-specific key material or identifiers into the vehicle components to be protected can be omitted.In contrast to the central procedure mentioned above, it is no longer necessary to permanently store the keys or the information underlying them so that after an authorized replacement of a vehicle component, the same key for the vehicle can be inserted into it again.

[0014] According to a preferred embodiment of the invention, the validity of the added block is checked by several other vehicle components, and a majority decision is made as to whether the new block is accepted. Such simultaneous validity checking by several vehicle components can significantly increase the reliability of the process.

[0015] It is particularly advantageous if a vehicle component in which no data structure is yet stored initially adopts the first data structure received from one of the other vehicle components.

[0016] According to a further embodiment of the invention, in the case of a vehicle component that was originally installed in a first vehicle, the data structure stored in the vehicle component is deleted in order to authorize commissioning in another vehicle.

[0017] According to a further embodiment of the invention, if different versions of the data structure are present in the vehicle components of the vehicle, the data structure present in the majority of the vehicle components is used.

[0018] Advantageously, the vehicle usage data includes at least the vehicle’s mileage.

[0019] The method according to the invention is preferably used in several vehicle components of a motor vehicle.

[0020] Further features of the present invention will become apparent from the following description and claims in conjunction with the figures. Fig. 1 schematically shows an exemplary embodiment of the method according to the invention for securing vehicle components; Fig. 2 schematically shows a possible structure of a data structure used for carrying out the method according to the invention, with blocks generated by vehicle components that contain data on vehicle usage; and Fig. 3 schematically shows an exemplary combination of three vehicle components (A), in which the data structure is supplemented by a new block containing a newly recorded mileage (B), a check of the new block (C, E) and the respective consequences in the event of a positive (D) and negative (F) check result.

[0021] To better understand the principles of the present invention, embodiments of the invention are explained in more detail below with reference to the figures. It is understood that the invention is not limited to these embodiments and that the described features may also be combined or modified without departing from the scope of the invention as defined in the claims.

[0022] Figure 1schematically shows an embodiment of the method according to the invention for securing vehicle components in a vehicle. The securing of the vehicle components can be carried out in particular based on a data structure such as the so-called blockchain. In addition to component protection, this also enables tamper-proof storage of data on vehicle usage, such as the mileage, or a vehicle log with detailed information, for example, on past vehicle journeys, operating hours, accidents, and maintenance. Details on the data structure are provided below in connection with Figure 2 describe.

[0023] In process step 1, the first block of the data structure is stored in a vehicle component upon initial use without a previously stored data structure or after the data structure has been deleted. In a blockchain, this first block is also known as the genesis block. This first block is not calculated by a vehicle component but is statically specified.

[0024] In process step 2, vehicle usage data is collected from the vehicle's components. Vehicle usage data refers to any vehicle-related parameters determined at a specific point in time. For example, the following vehicle usage data can be collected: Mileage; information on usage periods such as the times the vehicle was started and parked or the duration of the respective vehicle use ("operating hours"); information on vehicle parking locations such as GPS coordinates; unique identifiers of the respective journeys using agreed IDs or random numbers.

[0025] However, other data essential for vehicle use can also be recorded, such as data that is required to be recorded in accordance with legal requirements or information about whether the vehicle is in a manual, semi-autonomous or autonomous driving mode or when it changes from one of these driving modes to another.

[0026] Data can be collected at specific times or events, such as the start or end of a vehicle journey, an accident, or vehicle maintenance, or at regular intervals without requiring a specific event. It can also occur, for example, when the recorded parameter changes by a specified amount or when a vehicle component is activated.

[0027] The captured data is then recorded as an entry in a new block in step 3 and secured by calculating the checksum for this new block. The checksum is included in the new block and enables later verification of the data integrity. Furthermore, the checksum of the most recent block in the data structure is included in the new block to initially locally link the new block to the existing data structure.

[0028] This can be done decentrally by the vehicle component that recorded the data. However, a new block can also be created centrally by a vehicle component specifically responsible for this, such as a central control unit, which can then, if necessary, combine several new entries of various vehicle usage data into the new block.

[0029] Since the data structure is distributed across the various vehicle components, they must agree on an extension of the data structure. To do this, the vehicle component containing the new block sends the new block, or the complete data structure with the new block added, to the other vehicle components in the vehicle in process step 4. This data exchange among the vehicle components to be protected can occur at regular intervals or immediately after new data is acquired or a new block is created.

[0030] The new block is then verified by the other vehicle components in process step 5. Each receiver first checks independently, using the checksum, whether the new block is valid.

[0031] A consensus algorithm, which in the simplest case makes a simple majority decision, then decides in process step 6 whether the new block is accepted. Such a majority decision can, for example, be made in such a way that if the checksum is validated by all other vehicle components involved in the verification, a majority or even just more than half of the vehicle components involved accept the new block.

[0032] While this could be circumvented, for example, in the event of intent to manipulate the system by replacing most or all of the other vehicle components involved in the inspection, this would be very complex and generally not cost-effective. For example, manipulating a vehicle's mileage would be virtually impossible if, in addition to manipulating the control unit that generates the mileage, a consensus would also require the replacement of control units such as the engine, transmission, and steering system control units. Vehicle components that are easily accessible and easy to remove can therefore be securely protected against theft by combining them with vehicle components that are difficult or expensive to replace.

[0033] It is also possible to provide for different weightings for validation by different vehicle components, with vehicle components that are difficult to remove being given a higher weighting.

[0034] If there is consensus in process step 6 that the new block is valid, it is appended to the vehicle's data structure in process step 7.

[0035] If, however, the verification of the new block in process step 6 results in a deviation in the checksum for the majority of the other vehicle components, the use of the vehicle component that wanted to add the new block to the vehicle's data structure is restricted in process step 8.

[0036] Figure 2 shows schematically a possible structure of a data structure used for carrying out the method according to the invention with blocks generated by vehicle components which contain data on vehicle usage.

[0037] The first block 21 within the data structure, unlike all other blocks, is not generated by one of the networked vehicle components during vehicle operation. Instead, it is generated in at least one of the vehicle components during vehicle production and firmly embedded in it. This first block can also be written during initialization at the end of production, but also into all vehicle components involved in data exchange within the vehicle.

[0038] To create a common data set as a starting point or initial consensus, any data can be written into a payload area 25 of the first block 21. In the example shown, the mileage and operating hours are set to zero. Furthermore, production information, such as the year of manufacture and the production plant, can also be advantageously stored here. In addition, or instead, a vehicle identification number, such as the chassis number, or the exact production date can also be stored.

[0039] Furthermore, the first block has a header 24 containing a checksum determined from the payload data. This allows the block to be protected from tampering. Hash functions or hash algorithms can be used for this purpose.

[0040] The blocks 22 following the first block also each have a header data area and a payload data area. The checksum of the immediately preceding block is stored in the header data, thus establishing a link between these two blocks.

[0041] In this example, the payload stores several pieces of information that were recorded by one or more vehicle components or control units at a specific time during vehicle use. For example, the current mileage and the current value of the vehicle's operating hours at that time are stored in the payload. Furthermore, this example provides for the entry type to be noted, i.e., whether the recorded data was recorded while driving, during maintenance, during an accident, or during another event. Finally, in this example, an area of the payload is reserved for further specific information, such as the type of accident.

[0042] Here, too, a checksum is determined for the payload data, which is stored in the header of the block in addition to the checksum of the previous block. The determined checksum is then used to concatenate the subsequent data block. In this way, any number of data blocks can be concatenated, starting from the first data block 21 to the last data block 23.

[0043] In addition to the checksums, the header data of the blocks may also contain timestamps that record the time of creation of the respective block or the event recorded therein.

[0044] Since a large number of different electronic components and control units are now installed in motor vehicles, a wide variety of other data can be stored in the user data in addition to the data shown as examples, or other data can be stored in the respective blocks of the data structure instead of the data mentioned.

[0045] An example with an addition of a new block to the data structure, which for the sake of clarity is limited to three vehicle components 31, 32, and 33, is shown schematically in Figure 3 shown.

[0046] Vehicle component 31, symbolized by an instrument cluster, provides the vehicle's current mileage. Furthermore, a vehicle component 32, for example, an airbag control unit, can provide data in the event of a vehicle accident, such as the deployment of an airbag or the severity of the crash. Finally, a vehicle component 33, for example, an engine control unit, can provide data regarding the vehicle's operating hours.

[0047] As in Figure 3AAs indicated, each of the three vehicle components can exchange data with the other two vehicle components. For this purpose, the vehicle components can be connected to one another via a data bus, for example, a CAN bus. However, wireless communication between the vehicle components can also be provided. The vehicle components 31, 32, and 33 each have the same data structure 34, which in the example shown comprises only three data blocks for the sake of simplicity.

[0048] If the vehicle component 31 now records a new mileage of the vehicle, for example after the end of a journey of the vehicle, this is, as in Figure 3Bshown, is recorded by vehicle component 31 in a new block 35. To enable verification of the new block by the other vehicle components, vehicle component 35 sends the data structure supplemented by the new block to the other two vehicle components 32 and 33. However, instead of the complete data structure, only the new block can be transmitted for verification. The new block is then verified in vehicle components 32 and 33 using the checksum contained in the new block.

[0049] If both vehicle components 32 and 33, as in Figure 3Csymbolized by a correction check mark, come to the conclusion that the new block is valid, they add it to their local version of the vehicle's data structure. The vehicle's data structure is assumed to be the data structure used by the majority of vehicle components at a given point in time. They then communicate the positive result of their majority decision to vehicle component 31, which then also adds the new block to its version of the data structure. Thus, in the case of a positive consensus decision, as in Figure 3D shown, the same data structure including the new block 35 is then present in all vehicle components.

[0050] However, according to Figure 3E If the vehicle components 32 and 33 detect a manipulation of the data structure by the vehicle component 31 based on a deviation of the checksum, then, as in Figure 3Fshown, this vehicle component is shut down or at least its functionality is restricted until further notice.

[0051] Different procedures can be used here, depending on whether the local data structure of the vehicle component 31 differs greatly or only slightly from the data structure of the vehicle.

[0052] If the local data structure is completely different from the data structure of the vehicle, it can be assumed that the vehicle component 31 originally originated from another vehicle. As a result, the vehicle component 31 can be blocked, which requires activation by an authorized company before it can be put into operation. Resetting a used vehicle component to authorize its operation in another vehicle can be done by deleting the data structure stored therein. The initiation of the deletion process must be protected against unauthorized access. The first data structure received from another vehicle component is then adopted.

[0053] However, if only a minor deviation is detected, for example that only the last one or two blocks are missing in the data structure, but all previous blocks are present with correct checksum values, it may be possible to conclude that there is a temporary malfunction of the vehicle component, which can be remedied by resynchronization with the vehicle's data structure.

[0054] A brand-new vehicle component subsequently installed in the vehicle, on the other hand, has no data structure at all. In such a case, the new vehicle component always initially adopts the first received data structure from another vehicle component previously installed in the vehicle, so that even subsequently installed brand-new vehicle components are immediately subject to component protection.

[0055] The invention can be used to protect any electrical components integrated into a vehicle, such as the various control units installed. It is also possible to incorporate the vehicle's corresponding key into the component protection. Reference symbol list

[0056] 1Process step with storage of a first block of the data structure 2Process step with recording data on vehicle usage 3Process step with creation of a new block 4Process step with transmission of the new block to other vehicle components 5Process step with verification of the validity of the new block 6Process step with majority decision on the validity of the new block 7Process step with addition of the data structure 8Process step with restriction of component usage 21First block of the data structure 22Blocks of the data structure following the first block 23Last block of the data structure 24Header data area 25Payload data area 31, 32, 33Vehicle components 34Data structure stored in the vehicle components 35New local block in vehicle component

Claims

1. Method for securing vehicle components, comprising the following steps: - capturing (2) data on vehicle usage by means of a first of a plurality of vehicle components; - supplementing (3) a data structure which is stored in the first vehicle component and contains a list of captured data on vehicle usage, wherein the captured data are stored in blocks (21, 22, 23) which are linked to one another in that each block contains a cryptographic checksum of the previous block, with a block having further data on vehicle usage, wherein the block is added by this first vehicle component and the added block contains a cryptographic checksum of the most recent block of the data structure; - transferring (4) the new block to at least one of the other vehicle components; and - checking (5) the validity of the added block by means of the cryptographic checksum contained therein and a version of the data structure present locally in the at least one other vehicle component, wherein if the result of the check is positive, the supplemented data structure is stored (7) in the at least one other vehicle component, and if the result of the check is negative, the range of functions of the first vehicle component is restricted (8) or said component cannot be put into operation in the vehicle.

2. Method according to claim 1, wherein the validity of the added block is checked by a plurality of other vehicle components and a majority decision is made (6) as to whether the new block is accepted.

3. Method according to either of the preceding claims, wherein a vehicle component in which no data structure is yet stored initially adopts the first data structure received from one of the other vehicle components.

4. Method according to any of the preceding claims, wherein, in the case of a vehicle component which was originally installed in a first vehicle, the data structure stored in the vehicle component is deleted to authorize the component being put into operation in another vehicle.

5. Method according to any of the preceding claims, wherein, if different versions of the data structure are present in the vehicle components of the vehicle, the data structure present in the majority of the vehicle components is used.

6. Method according to any of the preceding claims, wherein the vehicle usage data comprise at least the mileage of the vehicle.

7. Vehicle component which carries out a method according to any of the preceding claims in order to secure said component.

8. Motor vehicle which is configured to carry out a method according to any of claims 1 to 6 or has a plurality of vehicle components according to claim 7.