WO2020207748A1

WO2020207748A1 - Method for documenting data of a physical unit

Info

Publication number: WO2020207748A1
Application number: PCT/EP2020/057652
Authority: WO
Inventors: Christian Seiler
Original assignee: Daimler Ag
Priority date: 2019-04-11
Filing date: 2020-03-19
Publication date: 2020-10-15
Also published as: DE102019002663A1

Abstract

The invention relates to a method for documenting data of a physical unit (E), the data being captured and stored in the unit. The method according to the invention is characterized in that, in a first level (PL), the data are stored in a first data set (P), the storing of the data in the first level (PL) being logged, in a second level (TL) separate therefrom, in a second data set (T) assigned to the first data set (P) and being signed by the unit (E), whereafter the data sets (P, T) are stored independently of one another, the second data set (T) being stored in distributed ledge technology (DL).

Description

Procedure for the documentation of data of a physical unit

The invention relates to the documentation of data of a physical unit according to the type defined in more detail in the preamble of claim 1.

The documentation of data of a physical unit, in particular a high-quality physical unit, such as a building, a

Vehicle, ship, aircraft or the like is often decisive for the value of the physical unit, for example in the event of a later sale. So far, the documentation has been carried out, if at all, in various data memories, partly digitally, but partly still in conventional form, for example on paper. The availability of the data is therefore often full of holes, but in any case very complex in terms of finding the data and, in some cases, not very transparent for the user.

WO 2018/014123 A1 and US 2018/0018723 A1 derived therefrom attempt to solve this by transferring the data from various events that are here a

Happened to the vehicle, stored centrally. In practice, storage takes place from different sources. This means that the storage of the data is often very intransparent for the actual owner of the data, since he does not know and can only understand who, for example, is with extremely great effort

Vehicle saved which data when and how. In addition, this type of storage is often accompanied by inadequate protection of privacy, since the data can be viewed very easily by third parties, possibly captured by hackers, decrypted and assigned. In addition, manipulation of the data cannot be ruled out.

In order to be able to rule out at least the manipulation of the data, the method described in WO 2018/108685 A1 uses the so-called distributed ledger Technology, which is also known under the term blockchain technology. Data is stored accordingly at different nodes of a data network so that manipulation of a single data set can be carried out by the

The comparison with the data stored elsewhere is always noticeable, so that the data is made more or less tamper-proof. The problem with the mentioned WO 2018/108685 A1 is that the amount of data here becomes very large, since all of the data recorded and stored by the unit, for example a vehicle, is encrypted and stored in the blockchain for special events Makes effort very large, so that with a corresponding number of vehicles, a huge amount of data comes together very quickly.

For further prior art in the matter, reference can also be made to US 2018/0167217 A1, which describes the storage of data in a network.

The object of the present invention is to provide a method for documenting data of a physical unit, such as a vehicle, an aircraft, a building or the like, in which the data are recorded and stored in the unit, and in which A high level of security against manipulation and transparency of the stored data can be achieved with a manageable amount of data.

According to the invention, this object is achieved by the features in the characterizing part of claim 1. Further advantageous refinements of the method according to the invention are described in the dependent claims.

The core of the method according to the invention is the division of the data into a first level, which is also referred to below as the privacy layer, in which the data is stored in a first data set. In a second of them

independent level, which is referred to below as the trust layer. This storage of the data is logged on the trust layer in a second data record assigned to the first data record and signed by the unit. This second one

The data record in the trust layer does not contain the data itself, but only information about its storage, for example about the type of stored data, the time of storage and a reference to the unit generating the data. This second data record is used to log the first data record of the privacy layer in the level independent of this. The data records are then saved independently of one another. The second data record is thereby via the

Distributed ledger technology, i.e. stored in a blockchain.

The method according to the invention therefore separates the actual data in the first data record and the logging of the storage in the second data record on two separate levels. The second data record stored via the distributed ledger technology prevents manipulation in the manner known from the blockchain, so that this data and the corresponding signature of the unit can always be used to ensure that the assigned first data record has remained unchanged after storage is, and thus is authentic and with integrity and can be reliably assigned to the respective unit as a data source via a corresponding reference. This data is distributed by the distributed ledger technology in such a way that it is always available multiple times, so that even in the event of a failure, for example of hardware elements, a memory chip or the like, it is always available and traceably unchanged and the integrity of the first data records is documented and to back up.

According to a very advantageous development of the method according to the invention, it is further provided that the unit itself has a unique hardware-implemented identity, preferably a code. This unambiguous identity of the unit is brought into the respective unit in a hardware-implemented manner. In the example of one

Vehicle, aircraft, ship or the like, this could be done, for example, when setting up the corresponding unit via a code, for example a chassis number, which on the one hand is visibly attached to the unit and which on the other hand is incorporated into a memory chip that is physically fixed to the respective unit, so that the unit has a unique identity what the above

described technique is very beneficial in terms of assignment and signature.

According to a further very advantageous embodiment of the idea, hardware-based asynchronous encryption is used for the signature of the second data record.

A corresponding component within the unit, for example an electronic wallet in a crypto chip, can be used for this. This component has a private key that is only stored in the component and cannot be read out is. The component can, however, be addressed in such a way that it generates a key pair, which in turn consists of a private key known only to the component itself and a public key, the so-called public key. A signature of the second data set by the unit can in this case be verified and checked using the public key and can thus be clearly assigned to the unit.

As already mentioned, the data of the second data set can include different contents. According to a very advantageous development of the method according to the invention, the data of the second data record include at least one time stamp of the storage of the first data record; a reference to the unit or its identity as a data source; and / or a reference for assigning the second data record to the respective first data record. At least this data is stored accordingly in the log of the storage of the first data record in the second data record. According to an advantageous development of the idea, the reference to the unit itself can include, for example, its public key or an identification derived therefrom, so that all necessary checks and assignments can be carried out in the event of a check using the public key of the unit.

The reference for assigning the second data record to the first data record can include, for example, a hash value of the first data record. This technology can be used accordingly in all conceivable systems, so that the assignment via the hash value is correspondingly simple and efficient.

The method according to the invention can in principle be used in any type of network architecture. A classic architecture, as it is available today, for example, from vehicle manufacturers for communication with a fleet of vehicles they manufacture, is a client-server configuration with a large number of individual vehicles as clients and one or a few largely central and networked back-ends -Servers. The backend server (s) are then used, for example, to store and synchronize the data in the privacy layer whenever the vehicle has a network connection and can synchronize the data accordingly. The vehicle can then also use such a synchronization, analogous to the synchronization of the data of the privacy layer, to send the data of the trust layer, that is to say the second data set, to the corresponding server or servers forward to it from there in the sense of the distributed ledger technology

to save different nodes accordingly.

As an alternative to this “conventional” scenario of a client-server architecture, the method according to the invention can also be used in a peer-to-peer network according to a very advantageous development of the idea. The advantages of such a peer-to-peer network, which can in particular be implemented using the so-called Inter Planetary File System (IPFS), allow, for example, the forwarding of corresponding information very efficiently when it is in a local storage location nearby of the respective addressee so that they can download the data immediately. This is particularly useful in situations in which, for example, a car manufacturer sells a software update. For example, there are a few dozen vehicles parked in a parking lot, all of which are the same

Need a software update, it is sufficient if one of the vehicles has this

Downloads software update from a server or from another participating vehicle nearby. The data can then be passed on directly peer-to-peer via this vehicle. In such a case, especially when using an IPFS, the data is provided with a corresponding reference. This IPFS reference, which takes the place of a fixed Internet address for the data in a client-server network, can now be used in addition to or as an alternative to the hash value of the first

Data record can be used to reference this in the second data record.

The security against manipulation of the data in the privacy layer in the method according to the invention is now based on the unchangeable protocol of the second data record. In order to ensure, even in the event that the unit does not have a network connection, that the second data record is available unchanged, even if, for example, a hardware problem should occur, it can be provided according to a very advantageous development of the method according to the invention that the second data record is in the unit is replicated at least once, but preferably multiple times. In

different data systems of the unit, for example in a vehicle in different memory modules or control and / or regulating devices, the second data set can be stored in this way. Even in the event that there is no network connection, it is then ensured that the second data record is always available several times. This redundancy increases the reliability and protection against manipulation of the

method according to the invention. If there is then a network connection again, the corresponding second data set is synchronized with the copies located in the nodes outside the respective unit in this data set in order to have the full function of the blockchain process available again.

The actual data itself, which is stored in the first data set and was hardly affected by the previous description due to its arrangement in the privacy layer, can also be synchronized, for example in a client-server architecture on a central server or in the case of a peer -to-peer architecture in various end devices and are available with at least one backup. The documentation and the signature for checking the integrity of the data in the first data record can be implemented in the case of both open and encrypted data in the first data record. This allows a very high

Achieve data protection, for example if the data of the first data set are encrypted according to a very advantageous development of the idea. Synchronous encryption is then a good option so that, for example, the owner of the unit can use his private key to decrypt the data stored in the privacy layer at any time and view it accordingly. This possibility only exists for himself, while the data of the rusted layer that is also accessible to other data only includes the unchanged status of the first data record via the second data record

document and ensure.

In the case of a closed network, for example made up of vehicle manufacturers, licensing authorities and certified test centers, it would in principle also be conceivable that the data of the first data set could be stored and synchronized in unencrypted form within such a closed network so that they could be used there for anyone with authorized access to the Network and thus the data can be viewed. For example, the buyer of a vehicle could ask a registration authority, the vehicle manufacturer or, for example, a testing organization whether the mileage of the vehicle is the one that was given to him by the previous owner without prior manipulation, for example fraud cases such as manipulating the mileage display on a vehicle to be able to recognize. This example can of course also be transferred to the other above-mentioned and further conceivable values of physical units and corresponding value-creating or value-reducing events that can happen to these units. Further advantageous embodiments of the invention also emerge from the

Exemplary embodiment which below describes the method according to the invention again using an example with reference to the figures.

Show:

Fig. 1 is a schematic representation of the basic concept of the invention

Procedure;

2 shows a schematic illustration of the method according to the invention using the example of a client-server architecture; and

3 shows an exemplary illustration of the method according to the invention using the example of a peer-to-peer network.

In the illustration of FIG. 1, the basic concept of the present invention is briefly shown. The method according to the invention for documentation ensures that data generated by a unit E, for example a vehicle, a house, an airplane, a ship or the like, are stored securely and unchangeably, while a maximum of privacy for the possibly sensitive data and a maximum of transparency for the owner of the data is made possible. In the following exemplary embodiment, the method is based on a unique assignment of an identity to the unit E and a

hardware-based asynchronous encryption for the signature, which ensures that the data source on which the data is based is authentic.

As can be seen in the illustration in FIG. 1, the core of the idea is that the data which are present in a first level of an application level are divided up accordingly. The data from the application level labeled AL in FIG. 1, which is also called the application layer below, is divided into two different levels, a private level, the so-called privacy layer PL, and another level, the so-called trust layer TL. The data itself remains exclusively in the privacy layer PL and can be encrypted there as required, for example, or is only exchanged within a secured, defined network, so that in this case, encryption may also be dispensed with. In the Trust Layer TL it is so that the data via the Distributed Ledger technology can always be stored and synchronized with each other at different computer nodes at the same time.

Since the data collected by the application layer AL is then broken down into two data sets, a first data set on the privacy layer PL and a second data set on the trust layer TL, the actual data is only available in the first data set, while the second data set documents the storage of the first data set, but does not contain the data itself. As noted by the comment on-ledger in FIG. 1 in the trust layer TL, this second data record of the trust layer is always managed on-ledger in order to rule out manipulation. The data set of the privacy layer does not have to do this. This is why it is designated as off-ledger in the illustration in FIG. In principle, on-ledger management or at least with a certain number of backups would be conceivable here as well, provided that this is done separately from the other data record, and provided that it is encrypted accordingly in order to maintain privacy.

The unit E in the illustration in FIG. 2 has several data sources DS, which are designated here by way of example with DS1 and DSn for the first and the last of the data sources DS. The data of these data sources DS are in a secured

Control unit 1 and there imported into the application layer AL already known from FIG. The data as a whole are marked with an A as application data. The privacy layer PL and the trust layer TL are also located within the secured control device 1. As already mentioned, the data A of the application layer AL are now divided into a first data record P of the privacy layer, in which the actual data are stored. The data P can also be assigned to a unique identity ID of the unit E. For this purpose, the unit E has, for example, a crypto chip 4 with a built-in electronic wallet EW. A second data record T is now generated in the trust layer TL, which has an assignment to the first data record, for example via its hash value. It also contains a reference to the unit E, for example via its ID or a public key generated in the crypto chip 4 on the basis of the private key exclusively stored there. The data of the first data record P are via a

Communication and synchronization unit 2 passed on and stored in the example shown here in a database 3 of a back-end server BS. The database 3 is part of a central database for managing the private Data, so that the data as P1 to Pn of a plurality of events and / or units E are specified in the actual database module.

If the protection of this first data record P against viewing by third parties

is to be made, this data can also be encrypted, for example with a known symmetrical encryption, in order to ensure that only an authorized user who has the

has a corresponding private key of the encryption, which can also decrypt the data. Alternatively, it would also be conceivable to keep the data decrypted, for example, if the network in which the data is disseminated, in the example shown in FIG. 2, the unit E and the backend server BS represent a closed network in which only trustworthy persons are present

accordingly have insight.

The second data record T in the trust layer is referenced to the first data record P in the privacy layer, for example, as already mentioned above, via a hash value.

Otherwise, this second data record T only contains information for documenting the storage of the data from the data sources DS in the first data record P,

For example, a time stamp, a reference to the unit E and the reference to the first data record P. This second data record T is now signed accordingly via hardware-based asynchronous encryption, for which a key pair is generated via the crypto chip 4, which is only stored in the crypto chip and only this Cryptochip 4 known private key is based. The public key of this key pair is used to sign the second data record T, so that it is unchangeable, tamper-proof and unique. The data record T from the trust layer TL is then distributed over several data nodes, on the one hand within the unit, for which three replicators R are available here, in order to provide several sources for storing the second data record T even if there is no network connection. As soon as a network connection exists, the second data set is distributed further via the communication and synchronization unit 2 to the backend server BS and is stored there in the form of a blockchain via a control device 5 at many nodes of a distributed ledger network DL. This is indicated in the illustration in FIG. 2 by means of a symbol for a cloud which has the corresponding data records T. The concept of data storage via the privacy layer PL is based, as already mentioned, on the identity ID, which is stored irreversibly in the unit E, for example in the electronic wallet EW of the cryptochip 4. This chip 4 is used when the unit E is manufactured , for example a vehicle, physically connected to the unit E accordingly. In the data of the vehicle manufacturer in the above example, a visible identification number is generated as a unique code for the unit E and the public key of the electronic wallet EW is stored accordingly in connection with this identification number. This identification ID is then visibly affixed to the unit E itself, for example engraved and stored, so that the unit E has its own identity ID. The private key of the electronic wallet EW is only known to it. It is not stored in any other place and cannot be read from the electronic wallet EW. The method for documentation now uses the fact that all data are subsequently signed by the unit E, specifically using the private and public keys of the electronic wallet EW, which the cryptochip 4 generates asynchronously as a key pair as required. The pair's public key can be read out. Anyone who has the public key can then verify the signature of the data. This ensures that the data source DS and the consistency of the data itself are guaranteed. As already mentioned, in an advantageous development of the concept it can also be provided that the first data record P of the privacy layer is additionally encrypted symmetrically in order to keep it free from access by third parties. This key pair is then generated synchronously in such a way that the owner of the unit E knows the private key accordingly and can view his own data at any time and give it to a buyer, for example.

Another embodiment can be seen in the illustration in FIG. Instead of the previous structure in the form of a client-server architecture, the method can of course also be used in the context of a peer-to-peer network. The unit E, which is referred to here as unit E1, is unchanged compared to the previous structure and the description in FIG. About their communication and

Synchronization unit 2 is now connected in the manner of a peer-to-peer network not only to a back-end server that is still present here in principle, but which is purely optional here, but also to various other units, which are here with E2 to En are indicated by way of example. The difference now is that the first data records P of all units E1 to En in all Units E1 to En are cached, as well as in the optionally available backend server, so that a correspondingly high level of data security is created here.

However, this is actually not a storage on-ledger because it is based on the

corresponding units is restricted, and not the signature and

Has certification characteristics of the blockchain process. Rather, only backups of the data are stored in the individual units.

The second data records T are now again distributed accordingly over all units E1 to En, as are their own second data records T within the unit E. They are then passed on directly or indirectly from the units E1 to En to further nodes of the peer-to-peer network and stored there as a blockchain.

In this development, the concept is appropriately combined with the concept of the InterPlanetary File System IPFS, so that each data record P, T has a

The hash value of its content is referenced, and not, as in the conventional Internet, via a location where it is stored. The advantage is that the document can be replicated accordingly within the peer-to-peer network. If a data set is now retrieved somewhere, time can be saved accordingly by obtaining it from a source close by, and not necessarily from the source in which it was originally stored. This local concept can save time and, above all, data traffic, especially when forwarding similar data such as software updates to a large number of users. The same applies to dealing with local events such as an accident or the like, which can be passed on locally via a peer-to-peer network without having to appear nationwide.

Such a peer-to-peer network can, as indicated in FIG. 3, not only be used as part of the storage of the first data record P, but in particular also for the storage of the second data records T on-ledger. The individual units can then communicate with one another directly in the manner of a mesh network and accordingly distribute data quickly and reliably, especially if, for example, the backend server BS is not available or inaccessible or in the event of a local emergency, as already mentioned above. The management of the Trust Layer TL is also bi-directional, so that data can be distributed in both directions, and each individual unit thus also acts as a node of the distributed Ledger technology for storing the second data records T is used. With a corresponding number of units, this causes a certain amount of energy consumption and bandwidth and the data rate is used for content which at first glance does not serve the user of the unit E or its owner. But overall it comes to one

corresponding advantage if one concentrates on the whole fleet or the swarm of the individual units E. This advantage ultimately helps everyone involved, so that the above-mentioned supposed disadvantage does not remain as such when looking at the big picture.

Ultimately, thanks to the procedure described, the owner of the data has full control and full access to his data. This gives him full transparency about his own data and also allows everyone else to have a

corresponding transparency about the storage of the data by storing the second data records T at different nodes. Every storage of an event can be tracked and is forever in the blockchain

documented. The details and the actual stored data themselves are only visible to those who have the data owner's permission to view the data due to the separation into the privacy layer and the trust layer. This can be used both in a conventional system and in a completely decentralized peer-to-peer network of connected units E in order to securely exchange, preserve and manage the data in an unchanged manner.

Claims

1. Method for the documentation of data of a physical unit (E), whereby the data are recorded and stored in the unit,

characterized in that

in a first level (PL) the data are stored in a first data set (P), with the storage of the data in the first level (PL) in a second, assigned to the first data set (P) in a second, separate level (TL) Data set (T) is logged and signed by the unit (E), after which the data sets (P, T) are stored independently of one another, the second data set (T) being stored in distributed ledger technology (DL).

2. The method according to claim 1,

characterized in that

the unit (E) has a unique hardware-implemented identity (ID), preferably a code.

3. The method according to claim 1 or 2,

characterized in that

hardware-based asynchronous encryption is used to sign the second data record (T).

4. The method according to claim 1, 2 or 3,

characterized in that

the data of the second data set (T) include at least one of the following contents:

- Time stamp of the storage of the first data record (P); - a reference to the unit (E) as a data source (DS); and or

- A reference for assignment to the respective first data record (P).

5. The method according to claim 4,

characterized in that

the reference to the unit (E) comprises a public key or an identity (ID) of the unit derived therefrom.

6. The method according to any one of claims 1 to 5,

characterized in that

at least the second data set (T) is stored in a peer-to-peer network, preferably an IPFS.

7. The method according to claim 4, 5 or 6,

characterized in that

the reference for allocation to the respective first data record (P)

Includes hash value of the data of the first data record (P) or its IPFS reference.

8. The method according to any one of claims 1 to 7,

characterized in that

the second data set (T) is replicated in the unit (E) at least once.

9. The method according to any one of claims 1 to 8,

characterized in that

the data of the first data set (P) are encrypted, preferably with symmetrical encryption.

10. The method according to any one of claims 1 to 9,

characterized in that

the data of the first data set (P) are stored and synchronized within a closed network.