Method and device for securing a vehicle's speedometer reading and device for verifying a vehicle's speedometer reading

Abstract

Method for securing a speedometer reading (10) of a vehicle (1) in which a sequence of data records (21) containing speedometer readings (10), time data (12), vehicle identification data (11) and fill data (13) are stored in a database (4), wherein a hash value (14) is generated from the stored data records (21) and the hash value (14) is stored in a blockchain (15), characterized in that the database (4) is only accessible to an owner of the vehicle (1).

Description

State of the art

[0001] The invention is based on a method and devices according to the class of independent patent claims.

[0002] Methods for securing vehicle odometer readings are already known, in which the odometer readings are stored in encrypted form in an electronic control unit within the vehicle. The encryption aims to make subsequent manipulation of the data stored in the vehicle itself more difficult. As one approach, the vehicle data, particularly the odometer readings, can be stored multiple times in a multitude of different control units within the vehicle. Furthermore, there are methods in which the vehicle's odometer readings are stored in an external database, for example, at a vehicle manufacturer, a government institution, or another trusted institution such as a vehicle inspection agency.This approach, however, entails disadvantages under data protection law, as driver-specific data, such as the vehicle identification number and mileage, are stored with third parties, either the vehicle manufacturer, a trusted government institution, or another trust center. Additionally, the central storage of data with a (platform) provider also carries the risk that the stored data can be altered centrally in one location. Furthermore, in the case of a central (platform) provider, the data owner is responsible for the availability of the data service. This means that if the provider, for example, shuts down the data service, the data owner no longer has access to their data. Moreover, the data owner cannot share the data themselves but is dependent on the provider's service.Another difficulty is that these solutions are usually national and therefore do not allow for protection across national borders.

[0003] Patent DE 10 2016 215 914 A1 describes a method for determining device usage information such as mileage or operating hours and storing it in a blockchain. This decentralized and cryptographically linked storage is intended to make the data tamper-proof without requiring a central, trusted authority.

[0004] Patent DE 10 2016 007 472 A1 discloses a method for the tamper-proof documentation of vehicle data, such as mileage or logbook entries, in which hash values ​​of this data are registered in a public blockchain. To reduce costs and network load, it is also proposed to aggregate the data from many vehicles via a central server, which then writes a single combined hash value to the blockchain. Advantages of the invention

[0005] In contrast, the inventive method or device for securing a vehicle's odometer reading has the advantage that a vehicle owner retains full ownership of their data, while still allowing for highly reliable verification of the vehicle's mileage in the event of a sale or for other reasons. It can thus be ensured with a high degree of reliability that a vehicle has actually only traveled the distance indicated on the odometer. For this purpose, the data records containing the odometer readings are stored directly from the vehicle (from the relevant control units or directly from the sensor that measures the distance traveled) in a private database belonging to the vehicle owner.The odometer reading taken from the vehicle, along with the corresponding vehicle identification number (VIN), is encrypted within the vehicle using a specific private key belonging to the vehicle data owner. This ensures that this personal data (odometer reading, VIN) can only be read by authorized individuals who possess the corresponding digital key. Additionally, hash values ​​of these data records are generated and stored in a decentralized database (blockchain technology). This blockchain is maintained by a computer network comprised of multiple publicly accessible computers. Blockchain technology-specific cryptographic methods, as well as a consensus mechanism, protect the data stored in the blockchain against subsequent manipulation.By regenerating the hash values ​​from the stored data records and comparing them with the hash values ​​stored in the blockchain, the odometer reading of a vehicle can be reliably verified. In particular, this allows any change to the odometer reading to be retrospectively verified over a long period.

[0006] Further advantages and improvements result from the measures outlined in the dependent patent claims. For odometer verification, the hash values ​​of the stored data records are recalculated and compared with the hash values ​​stored in the blockchain. This simple comparison allows for the reliable detection of any data manipulation. Storing data records from various vehicles in the blockchain enables a large number of vehicle owners to benefit, thus justifying the associated operating costs. In particular, blockchain technology offers the advantage of being freely accessible and available to all interested parties (independent of vehicle manufacturers, end customers, OEMs, suppliers, etc.). This allows the technology to be used worldwide without dependence on, for example, a single (platform) provider.Furthermore, the blockchain stores additional identification data that allows the hash values ​​stored in the blockchain to be linked to the data records from which the hash values ​​were calculated. This makes it possible to individually verify the odometer reading for each vehicle within a large blockchain containing data from numerous vehicle users. The database containing the data records is designed so that the respective data is only accessible to the vehicle owner or the holder of the "digital key" for decryption. To make it more difficult to reverse engineer the data records from the hash values, the data records should also contain filler data to prevent such calculations.This is particularly important because all data stored in the blockchain is freely accessible to everyone via the internet, and odometer readings are continuously growing data, which could facilitate any potential calculations back from the hash values. Since verifying odometer readings requires complex calculations based on the blockchain, these calculations could, for example, be performed by a trust center. Drawings

[0007] Exemplary embodiments of the inventions are described in the Fig. Figures 1 to 3 are shown and explained in more detail in the following description.

[0008] They show: Fig. 1 a vehicle, a mobile phone and a cloud which together implement the method according to the invention, Fig. 2. A vehicle, an application server, and a cloud that together realize the inventions, and Fig. 3. Verification of the odometer reading by a trust center. Description of the exemplary implementations

[0009] In the Fig. Figure 1 shows a first embodiment of the invention, wherein the method according to the invention is realized here by an interaction of a vehicle 1 with a mobile phone 2 and a cloud 3, i.e., a computer network consisting of a plurality of computers. The vehicle 1, whose odometer reading is to be secured, continuously or at regular intervals transmits its odometer reading 10 to the mobile phone 2. In addition to the odometer reading 10, vehicle identification data 11, for example, a chassis number, can also be transmitted from the vehicle 1 to the mobile phone 2. Furthermore, this data can be directly signed and hashed in the vehicle or in the respective sensor or control unit in the vehicle. By means of the personal signature (e.g.,By using a "private key" to the relevant data in the vehicle, this data can be transmitted from the vehicle in encrypted form, ensuring that no third party can view this personal data. Alternatively, it is also possible for mobile phone 2 and vehicle 1 to be paired, so that the complete vehicle identification data 11 is only transmitted when vehicle 1 and mobile phone 2 are paired. Mobile phone 2 has access to a database 4 and a cloud 3. This database 4 can be, in particular, a database provided within mobile phone 2 itself. Alternatively, the database 4 can also be external to mobile phone 2, in which case data exchange between mobile phone 2 and database 4 should only take place in encrypted form.From the odometer readings 10 and the vehicle ID 11, mobile phone 2 generates a data record 21, which is stored in database 4. In addition to the odometer reading 10 and the vehicle ID 11, data record 21 also contains time data 12 and filler data 13. The time data 12 assigns the odometer reading 10 to a specific time. This time data 12 can consist of a date or other time data that allows the odometer readings to be assigned to a specific time. For example, the time data 12 could simply contain the elapsed time since the vehicle 1 was first put into operation. Furthermore, filler data 13 is included. This filler data serves to assign a specific amount of content to the data records 21 in order to make it more difficult to reconstruct the content of the data records 21 from a hash value generated from them. In particular, the filler data 13 should consist of random filler data.The mobile phone 2 calculates a hash value 14 from the data records 21, which is given to a cloud 3 (blockchain technology).

[0010] The storage of the odometer data 11 in the data records 21 can be handled variably. To minimize the computational effort, for example, the odometer readings 11 could be stored in a data record 21 only once a week. Alternatively, a corresponding odometer reading 10 could be stored after each trip of the vehicle. This could also occur at fixed or random times. Another possibility is to store an odometer reading 10 whenever a connection is established between the vehicle 1 and the mobile phone 2. Furthermore, it is not necessary to calculate a hash value 14 from every data record 21. Several data records 21 can also be combined to generate a single hash value 14.The generation of the hash value can also take place at fixed predetermined times, at regular intervals, or randomly from time to time, or only when a connection is established between the mobile phone 2 and the cloud 3.

[0011] The hash values ​​4 calculated from the data records 21 allow verification of the authenticity of the data records 21 against subsequent manipulation of the database 4. Thus, if a history of odometer readings and associated times has been recorded through the regular storage of data records 21, the hash values ​​14 can be used to verify whether these data records 21 have been subsequently altered. However, this requires that the hash values ​​14 also be stored in a way that prevents subsequent manipulation of the hash values ​​14 or the complete re-uploading of data records 21 and hash values ​​14. This is achieved by regularly uploading the hash values ​​14 to a cloud 3 (blockchain technology), i.e., a network of multiple computers, and storing them in a blockchain 15.

[0012] Such a blockchain 15 is a decentralized database to which new data in the form of transactions, in particular new hash values ​​14, are continuously added. To ensure the integrity of this blockchain, the new hash values ​​14 added to the existing blockchain 15 are secured by calculating a new hash value from the existing data of the blockchain 15 and the new hash values ​​14. This new hash value is then stored together with the data, thus forming a new block of the blockchain 15. Such a blockchain 15 is therefore a continuously growing dataset from which all data added since the beginning of the blockchain 15 can be traced back; that is, all newly stored hash values ​​14 can be calculated by recalculating them from the current blockchain 15.Due to the comprehensive calculations required, it is virtually impossible to manipulate blockchain 15 to alter a previously added hash value 14. This ensures particularly secure storage of the hash values ​​14, which can be used to confirm the authenticity of the data records 21. Furthermore, the respective blockchain database 15 is decentralized and exists on all participating computers. Whenever new hash values ​​14 are added to blockchain 15, every copy of blockchain 15 on all participating computers is updated. The various computers in Cloud 3 coordinate with each other via a consensus mechanism to determine the status of the latest valid blockchain 15. Therefore, even if it were possible to alter a single copy of blockchain 15 through complex calculations, this would be easily detectable by comparing it with the other copies of blockchain 15.

[0013] Hash values ​​are generated from the data records 21, allowing verification of the data records 21 once the authenticity of the hash values ​​14 is established. Since the hash values ​​14 are continuously stored in a blockchain 15, their authenticity is ensured by the blockchain 15. The security of the blockchain 15, in turn, is ensured by the fact that numerous copies of the blockchain exist on a multitude of distributed computers, thus preventing manipulation of the blockchain 15 on a single computer by comparing the different copies of the blockchain 15 across these computers. A process is described in which the odometer readings of a vehicle 1 are stored in a database 4, with the authenticity of this database being ensured by the blockchain 15, which is stored in parallel on numerous computers in the cloud 3 (blockchain technology).This method therefore achieves the greatest possible security in safeguarding the odometer readings of a vehicle.

[0014] To verify the odometer reading of vehicle 1, at least one data record 21 from memory 4 must be verified by determining the corresponding hash value 14 from blockchain 15. This verification can be performed either on all data records 21 in memory 4 or only on the last data record 21 in memory 4. Since evaluating blockchain 15 requires more complex calculations, such verification of one or all data records 21 in database 4 is typically carried out by a trust center 22. A trust center 22 is a computer controlled by a trusted institution. Such an institution could be, for example, a government agency or another trusted organization, such as a vehicle inspection agency.Alternatively, this service may be offered online by a service provider. For such a verification of an odometer reading to take place, the owner of vehicle 1 must grant access to database 4. Trust center 22 can then access the raw data (records 21) to be verified in the respective database 4. Furthermore, trust center 22 can access the transactions and hash values ​​corresponding to the raw data in blockchain 15. Trust center 22 calculates the corresponding hash values ​​from the provided raw data (records 21) and compares these hash values ​​with the data stored in blockchain 15. If both hash values ​​14 match, the authenticity of the raw data (records 21) in database 4 is confirmed.

[0015] As an alternative to an external mobile phone 2, the communication device can also be a unit permanently installed in the vehicle 1. For example, many vehicles today already contain a communication computer that can exchange data with the cloud 3 via a GSM mobile phone or other data connection. Accordingly, the database 4 could then also be located directly in the vehicle. Alternatively, the database 4 can also be located in the cloud, in which case encrypted communication with the database 4 is necessary.

[0016] Instead of using a trust center 22, odometer readings can also be verified by having a suitable evaluation program running on a computer. The owner of vehicle 1 would then send the data records 21 to this computer. This computer then reads the transactions (hash values) corresponding to the data records 21 from blockchain 15 and compares the corresponding hash values ​​from data records 21 and blockchain 15. For example, a buyer of a car wants to verify the authenticity of the odometer reading. To prove the authenticity of the odometer reading to the buyer, the seller of vehicle 1 grants the buyer access to database 4. The buyer reads the corresponding transactions (hash values) from blockchain 15 and calculates the hash values ​​of the data records 21 provided by the seller from the raw data (database 4).By comparing the hash values ​​stored in the blockchain 15 with the hash values ​​determined from the data records 21, a buyer of a vehicle can verify the accuracy of the odometer reading without relying on a third party. Alternatively, this accuracy can of course also be ensured by the operator of a trust center 22, who offers this as a service.

[0017] In the Fig. Figure 2 shows an alternative embodiment in which an application server 200 of a service provider is used instead of a mobile phone 2. This application server 200 is designed as a computer that performs the same functions as the mobile phone 2 in the Fig. 1. This means that the application server 200 receives the odometer readings 10 and the vehicle ID 11 and uses them to create corresponding data records 21, which are stored in a database 4 via an encrypted connection 210. The respective data (odometer readings 10 and the vehicle ID 11) can also be directly signed and hashed in the vehicle (control unit, sensor) with the vehicle data owner's private key, so that the owner or operator of the application server 200 cannot view the personal vehicle data. Furthermore, the application server 200 determines the corresponding hash values ​​14 from the data records 21 and communicates these to the cloud 3 for storage in the blockchain 15. Alternatively, the application server 200 can also receive the data records from an OEM computer 201. Such an OEM computer is a computer belonging to the manufacturer of the vehicle 1, which continuously receives data from the vehicle 1 for diagnostic purposes.This data includes, among other things, the odometer readings (10) and the vehicle ID (11). The OEM computer (201) then forwards this data (10, 11) to the application server (200). Crucially, the application server (200) does not transmit any unencrypted data. Both the data storage in memory (4) and the data exchange with the cloud (3) are carried out via an encrypted connection (210).

[0018] In the Fig. Section 3 will present further details of the verification process using Trust Center 22. Trust Center 22 is connected to Application Server 200, as already mentioned. Fig. As described in section 2, the application server 200 connects to and receives the hash values ​​14 corresponding to the data records 21 from the application server 200. The application server 200's computer reads the hash values ​​14 from blockchain 15. Alternatively, the trust center 22 can also read the hash values ​​14 directly from blockchain 15 or receive them directly from a computer in cloud 3, which holds a copy of blockchain 15. In any case, the trust center 22 has the corresponding hash values ​​14 for the data records 21 available for comparison purposes. The data records 21 are supplied using a mobile phone 2, which is under the control of the vehicle owner. The mobile phone 2 accesses database 4 and receives encrypted data 210. By decrypting this data 210 transmitted from database 4, the original data records 21 are recovered.Accordingly, mobile phone 2 then transmits the decrypted data records 21 to trust center 22 for the purpose of verifying that this data has not been falsified. As already described, the hash values ​​14 are calculated again from the transmitted data records 21 and compared with the hash values ​​14 that were stored in blockchain 15. Alternatively, the vehicle owner can also grant the trust center access to database 4 by providing an encryption code or access authorization, allowing trust center 22 to directly retrieve the data records 21 through direct communication with database 4.

[0019] The described method can be used not only to safeguard odometer readings of a vehicle, but also to safeguard any operating data of a technical object or machine. Instead of odometer readings, operating times, loads during operation, measured values, sensor data, actuator control data, or any other operating data of an object or machine could be safeguarded. This operating data, along with time data, identification information for the technical object or machine, and fill data, is then stored in a database according to database 4, as described in the [reference to database 4]. Fig.The data described in sections 1 to 3 is stored. Hash values ​​are then generated from these stored data records and saved in a blockchain. By repeatedly saving operational data and storing the corresponding hash values ​​in the blockchain, an operational history of any technical object or machine can be created and reliably recorded by storing the corresponding hash values ​​in the blockchain. Examples would be the operating times of a machine tool or construction machine, or the mechanical stresses or special characteristics that occur during operation. Any type of measurement data from a technical device can thus be collected in a database (4) and verified by storing the hash values ​​in a blockchain.This is particularly relevant when equipment is rented out and the rental price is calculated not only based on time but also on operating duration or stresses during the rental period. By storing the operating data in corresponding datasets and transmitting the hash values ​​to a blockchain, it is possible to reliably track the stresses a specific piece of equipment has been subjected to over an extended period.

Claims

[1] Method for securing a speedometer reading (10) of a vehicle (1) in which a sequence of data records (21) containing speedometer readings (10), time data (12), vehicle identification data (11) and fill data (13) are stored in a database (4), wherein a hash value (14) is generated from stored data records (21) and the hash value (14) is stored in a blockchain (15), characterized by , that the database (4) is only accessible to an owner of the vehicle (1). [2] Method according to claim 1, characterized by , that to verify the odometer reading (10) from the stored data records (21) hash values ​​(14) of the data records (21) are recalculated and compared with stored hash values ​​(14) in the blockchain (15). [3] Method according to any of the preceding claims characterized by, that in the blockchain (15) hash values ​​(14) of data records (21) of different vehicles (1) are stored and when new hash values ​​(14) are stored in the blockchain (15) the blockchain (15) is updated on a large number of computers. [4] Method according to any one of the preceding claims, characterized by , that in addition to the hash values ​​(14) further identification data are stored in the blockchain (15) which allows an assignment of the hash values ​​(14) to the data records (21) from which the hash values ​​(14) were calculated for the verification of the odometer readings (10). [5] Method according to any one of the preceding claims, characterized by , that the fill data (13) are chosen in such a way that it is difficult to reverse engineer the data records (21) from the hash values ​​(14). [6] Method according to any one of the preceding claims, characterized by, that the verification is carried out by a trust center (22) which recalculates the hash values ​​(14) of the data records (21) from the data records (21) and compares them with stored hash values ​​(14) in the blockchain (15). [7] Device for securing a speedometer reading (10) of a vehicle (1) which stores a sequence of data records (21) containing speedometer readings (10), time data (12), vehicle identification data (11) and fill data (13) in a database (4) from speedometer readings (10) of a vehicle (1), generates a hash value (14) from the stored data records (21) and passes the hash value (14) to a blockchain (15) for storage, characterized by , that the database (4) is only accessible to an owner of the vehicle (1). [8] Device for verifying a vehicle's odometer reading in which at least one data set (21) containing an odometer reading (10), time data (12), vehicle identification data (11) and fill data (13) is read from a database (4), wherein a hash value (14) is generated from the data set (21) and the hash value (14) is compared with a hash value from a blockchain (15), characterized by , that the database (4) is only accessible to an owner of the vehicle (1).

Images