Patent ID: 12206791

DETAILED DESCRIPTION

FIGS.1aand1billustrate the method steps a) to q) of an exemplary embodiment of the method for securely providing data of an object over the entire life cycle thereof, which are carried out sequentially. The connector symbol labelled “1” in a circle provides the connection between method step (h) inFIG.1aand method step (i) inFIG.1b.

It is assumed, here, that the life cycle of the object does not just begin with its production, but already beforehand, and that before its production the object is existent as an object type and then, with the start of its production, as at least one object instance, and that each object instance is derived from the object type, and that each object type and each object instance is represented by a respective individual entity. In this case, the number of object instances will then correspond to the number of items produced. By being derived from an object type, the object instance can take over or inherit at least part of the data relating to the object type.

The method will now be discussed in more detail for a newly generated object instance.

However, before method step (a) can be started, an entity representing the object instance must first be generated, which is made identifiable on the basis of a cryptographic identity by generating an asymmetric key pair, comprising a public key and a private key, and which is made addressable on the basis of a first hash value, for example, which is generated using a cryptographic hash function that is based on the public key of the entity. The method then comprises the following additional steps:

In step (a), data are generated which relate to the object instance and which are to be provided. This may be any data which specify features of the object instance, for example, or which describe properties and/or functions of the object instance. In any case, this data will then be structured hierarchically in files and folders.

In step (b), a second hash value is generated on the basis of the data from step (a) using a cryptographic hash function. For this purpose, depending on the number of files and/or folders existent, at least one file hash value and/or folder hash value is generated successively, starting at the lowest hierarchical level up to the highest hierarchical level. For each file, a file hash value is generated on the basis of the file content thereof, using a cryptographic hash function. Furthermore, for each folder that only contains a number of files, a folder hash value is generated on the basis of the file names and the file hash values of the files contained in the folder, using a cryptographic hash function. Furthermore, for each folder that only contains a number of folders, a folder hash value is generated on the basis of the folder names and the folder hash values of the folders contained in the folder, using a cryptographic hash function. Furthermore, for each folder that contains a number of folders and a number of files, a folder hash value is generated on the basis of the folder names and the folder hash values of the folders contained in the folder and on the basis of the file names and the file hash values of the files contained in the folder, using a cryptographic hash function. Until, finally, the second hash value is generated on the basis of the folder names and the folder hash values of the folders present on the highest hierarchy level and/or based on the file names and file hash values of the files present on the highest hierarchy level.

In step (c), a new revision status is generated.

In step (d), the data generated in step (a) and the second hash value generated in step (b) are stored as payload data in the revision status generated in step (c). In addition, in this example, the address of the entity is also stored as additional data in the revision status of step (c), in order to link the new revision status with the entity. Thus, the revision status and its content are associated with the entity. Furthermore, in addition to the payload data, the third hash value of a revision status of the object type is stored in the revision status of step (c) (not shown inFIG.1a) and, thus, a link to this revision status is established. The data of the new revision status of the object instance then possibly supplement or overwrite the data of the linked older revision status of the object type. Furthermore, in addition to the user data, the revision status of step (c) stores an author of the revision, a revision date, a revision time, a text describing the revision, and/or a data volume value, in particular in the form of metadata of the revision status, the metadata also being additional data.

In step (e), a third hash value is generated on the basis of the revision status using a cryptographic hash function. Both the user data and the additional data stored in the revision status are taken into account for this. The third hash value then serves as the address of the revision status.

In step (f), a new data object is generated, which is intended for being stored in a decentralized distributed content-addressed storage system which may be configured according to the InterPlanetary File System (IPFS).

In step (g), a name is generated for the revision status and is assigned to the revision status. The name may, for example, be a designation or a version number which is easily comprehensible in particular for the user. The assignment may be achieved, for example, by linking the name with the third hash value that serves as the address of the revision status. Subsequently, the revision status, the third hash value, and the name are stored in the data object of step (f). Then, the data object containing the revision status, the third hash value, and the name assigned to the revision status is encrypted using a randomly generated symmetrical session key. Once the data object has been encrypted, the symmetric session key is encrypted with the asymmetric public key of an intended recipient. Furthermore, a fourth hash value is generated on the basis of the data object using a cryptographic hash function, the fourth hash value serving as the address of the data object.

Finally, in step (h), the data object is stored in the decentralized distributed content-addressed storage system.

In addition, a permanent message in the form of a transaction is intended to be generated for the revision status stored in step (g) and to be stored in a decentralized storage system based on blockchain technology (blockchain storage system). The blockchain storage system already stores at least one data block which includes data content and a hash value, which hash value was generated on the basis of the data content of the data block using a cryptographic hash function and serves as the address of the data block. Should there actually exist only a single data block stored in the blockchain storage system, it is known as genesis block which represents the first data block in the block chain and is the only data block that does not refer to a previous data block. However, further data blocks may already have been stored in the blockchain storage system. The following further steps are therefore contemplated:

In step (i), a new transaction is generated, which is intended to function as a permanent message about the storing of the revision status performed in step (g).

In step (j), the fourth hash value is stored as part of transaction data in the transaction of step (i) and, thus, the new transaction is linked to the data object from step (h) which stores the revision status. Furthermore, a current time stamp is generated and stored as part of the transaction data in the transaction (not shown inFIG.1b). In addition, the encrypted session key from step (g) is stored as a further part of the transaction data in the transaction of step (i). Additionally, a signature (not shown inFIG.1b) is stored as part of the transaction data in the transaction, the signature being a numerical value identifying the originator of the transaction, which is generated on the basis of the fourth hash value and an asymmetric private key of the originator using an asymmetric cryptographic function. In another example, not shown, additional parts of the transaction data may also be taken into account when generating the signature.

In step (k), a data block is then generated in accordance with blockchain technology.

In step (l), the transaction is stored in the data block.

In step (m), a fifth hash value is determined, this being the hash value of the data block most recently stored in the blockchain storage system.

In step (n), the fifth hash value is stored as additional data content in the data block of step (k).

In step (o), a hash value is generated for the data block based on the data content of the data block using a cryptographic hash function, the hash value serving as the address of the data block.

In step (p), the hash value generated in step (o) is stored in the data block.

In step (q), the data block is stored in the blockchain storage system which also stores the data blocks created at earlier points in time. This documents the storing of the revision status in the blockchain, i.e. in the blockchain storage system.

In a further exemplary implementation of the method, not illustrated inFIGS.1aand1b, which is performed with regard to an object instance, step d) may comprise to store, in the new revision status of an object type, as additional data in addition to the payload data, the third hash value of a revision status of a further object type or the third hash values of revision statuses of several further object types, thereby establishing links to these revision statuses. This would be the case if the object type is a type of object composed of a plurality of object types or is an object type having a modular structure.

In a further exemplary implementation of the method, not illustrated inFIGS.1aand1b, which is performed with regard to an object instance, step d) may comprise to store, in the new revision status of an already existing object instance, as additional data in addition to the payload data, the third hash value of an older revision status of the object instance, thereby establishing a link to the older revision status. In this case, the data of the new revision status will then optionally supplement or overwrite the data of the linked older revision status.

In a further exemplary implementation of the method, not illustrated inFIGS.1aand1b, which is performed with regard to an object instance, step d) may comprise to store, in the new revision status of an already existing object instance, as additional data in addition to the payload data, the third hash value of a new revision status of the object instance, thereby establishing a link to the new revision status of the object type. This would be the case when a revision or update such as a firmware update was provided as a new revision status of an object type, which is to be accepted for the object instance derived from the object type.

A recipient which, based on a permanent message in the blockchain storage system desires to read and optionally further process the data of the referenced revision status, will substantially simply carry out the process steps in reverse order. Thus, the recipient will first read the transaction data from the transaction serving as a permanent message within the blockchain storage system. He or she will thus obtain the fourth hash value, which addresses the data object containing the revision status, the time stamp of the storage of the transaction, the session key encrypted with his or her asymmetric public key, and the signature of the originator or publisher of the transaction. Using the asymmetric private key, the recipient will be able to decrypt the session key. Using the fourth hash value, the recipient retrieves the corresponding data object in the decentralized distributed content-addressed storage system and will find therein the revision status encrypted with the symmetrical session key together with the assigned name and the third hash value, which he or she can decrypt using the previously decrypted session key and then read.

FIG.2shows an exemplary embodiment of the system for carrying out the method for securely providing data of an object over the entire life cycle thereof. It comprises a communication network N and four subscriber nodes K1, . . . , K4, each subscriber node including a storage device and a processing device as well as a communication device for being coupled to and communicating via the communication network, although not illustrated inFIG.2.

On the one hand, the exemplary system is designed as a decentralized distributed content-addressed storage system, where each one of the illustrated subscriber nodes is able to store data relating to an object in its storage device and to provide these data to the other subscriber nodes via its communication device and the communication network, in particular according to the peer-to-peer principle. On the other hand, the system, via its communication network, is connected to a further storage system (not shown in greater detail inFIG.2), which is used to store messages about stored revision statuses in the form of transactions, and which is based on blockchain technology and is also designed as a decentralized distributed system (blockchain storage system).

Furthermore, a machine-executable program code is stored in the storage device of each subscriber node, which, when executed by the processing device of the respective subscriber node, causes the data relating to an object to be provided in accordance with the method according to the invention.

Subscriber nodes K1, K2, and K3are object instances. Subscriber node K4is not an object instance, but makes available its resources, in particular computing, storage, and communication resources, to the object instances G1and G2which are in communication connection with the subscriber node K4for reasons of insufficient computing and/or storage capacity.

For the sake of better comprehension, essential aspects and findings on which the invention is based will now be explained in more detail with reference toFIGS.3through11.

FIG.3shows four basic requirements for the functioning of the method of the invention. Accordingly, an identity model1and a content model2are first required, on which a distribution model3is based, on which in turn an interaction model4is based.

FIG.4illustrates the identity model which is one of the basic requirements. Accordingly, there are persons5, (object) types6, and (object) instances7, all of which are entities8or are represented by entities8which can be provided with data. Persons, types, and/or instances, as actors, are able to change the descriptive data of persons, types, and/or instances. All entities are identified by a cryptographic identity9. In the proposed method, the cryptographic identity is an asymmetrical cryptographic key pair10which consists of a publicly known key and a private key. A cryptographic one-way function (hash function) is used to derive, from the publicly known key, an address11which can be used to name or address the identity.

As a result of a development process, for example, the manufacturer of a product (e.g. power supply unit) or of a composite product (e.g. switch cabinet) generates a type. The type represents the production specification in digital form. As a result of a production process, for example, the manufacturer of the product (e.g. power supply unit) or of a composite product (e.g. switch cabinet) generates an instance based on a type. The instance represents the physical object in digital form.

FIG.5illustrates the content model which is one of the basic requirements. The data relating to a person or to an object or to an object type or to an object instance are structured or organized in files15, folders14, and revision statuses13which can be retrieved via names12and are linked to the entity. In other words, an entity8comprises a finite list of names12, and each name points to a revision status13of the entity.

In the case of a type, for example, sequential numbers, version numbers, maturity level descriptions, or project milestones can be used as names. In the case of an instance, for example, production steps, revision cycles or the designation of service processes can be used as names.

A revision status contains at least one author, a revision date, and a revision text (not shown inFIG.5). Furthermore, a revision status points to a hierarchical structure of folders14and files15in which the data are contained or organized. Files, folders, and revision statuses can be addressed using cryptographic checksums (hash values) which are generated from the content of the data using cryptographic hash functions and which represent unique and unchangeable primary keys (not shown inFIG.5).

The data describe the properties and functions that an entity possesses, and the properties and functions can be of technical or of commercial nature, for example.

Furthermore, each revision status may refer to one or more previous revision statuses. Thus, a history of the entity's data is represented.

Examples of specifying data of a type are classification data, drawings, circuit diagrams, data sheets, instructions, product photos, and descriptive product texts. In the case of composite products, types may contain references to the revision statuses of other types.

Examples of specifying data of an instance are serial numbers, test reports, parameters, programs, status data, installation location, and installation history. In the case of composite products, instances may contain references to the revision statuses of other instances. Instances furthermore contain references to revision statuses of the type on the basis of which the instance was generated.

The following table shows examples for how an instance is derived from a type by a process.

TypeProcessInstancePHOENIX CONTACTproductiondevice withArticle 2904600serial numberpower supply unit -21751T0352QUINT4-PS/1AC/24DC/5Configurable articleconfigurationconfigured articleDistribution blockwith articlePHOENIX CONTACTnumber 9876543PT-FIXSoftware source code forcompilation/linkingsoftware object codecontrol firmware(executable file,e.g. “BIN”,“EXE”, “OBJ”)Equipment designinstallation/assemblyinstalled equipment(descriptive datamachine BM-12345including, e.g.,circuit diagram, drawings,instructions, programs)

FIG.6illustrates the distribution model, which is one of the basic requirements, with regard to write authorization. At certain points in time during the life cycle of an entity, entities exchange data. The entity that wants to provide new or changed data is referred to as the publisher17. The publication18relates to the same or to a different entity (e.g. type/instance) and contains the revision status13that is to be transferred or made available. What is referred to as publication, here, is the data object that is stored or made available in a decentralized distributed content-addressed storage system.

The publisher releases the publication by digitally signing it with the private key of his identity and transmitting it to a decentralized network19, and, strictly speaking, only a hash value generated on the basis of the data object is signed and transmitted. The decentralized network in the form of a decentralized distributed storage system based on blockchain technology (blockchain storage system) is characterized by meshed communication subscribers (subscriber nodes) and structurelessness. For example, no star structure, ring structure or otherwise defined structure is required to operate such a network. The network confirms the publication if the digital signature is valid and makes available the referenced information within the network.

The network ensures that the transaction cannot be undone and that its content cannot be changed. Moreover, the use of a digital signature defines the write authorization of the distribution model, since provisions are made so that, generally, a transaction without a signature cannot be stored.

FIG.7illustrates the distribution model, which is one of the basic requirements, with regard to read authorization. Accordingly, the publisher17also determines the entity or entities that are intended to have read access to the publication18. These entities are the addressees or intended recipients of the publication. Based on the publication, the publisher creates a transfer object (21) by encrypting the publication using a randomly generated session key (22). The session key is exchanged with the addressees in encrypted form using their public keys. The publisher makes available the transfer object in the network.

Like the publication before, the transfer object is also addressed by its cryptographic checksum (hash value).

Thus, the read authorization of the distribution model is defined by the use of encryption.

FIG.8illustrates the interaction model which is one of the basic requirements. Based on the distribution model, the proposed interaction model offers three possible actions for interaction during the life cycle.With the publication derivation20, an entity is able to generate a new publication based on another publication (see alsoFIG.9).With the revision proposal21, a publisher signals to another publisher that revisions to an entity are existing in the form of a new publication and at the same time recommends their acceptance (see alsoFIG.10).The other publisher can decide to accept the revision22(see alsoFIG.11) or can reject the proposed revision.

FIG.9illustrates the sequence of a publication derivation (see alsoFIG.8). The publication derivation is based on the methods for reading and writing information as defined in distribution model3(seeFIGS.6and7). The publication derivation allows the provision and thus the forwarding of information about an entity X from an entity A to an entity B. For this purpose, entity A first generates a publication PA that relates to entity X and contains or refers to a revision status. Being the publisher of the publication, entity A designates the entity B as one of the addressees. This allows the entity B to read the contents of the publication. With the available data, entity B is able to derive a new publication PB. Publication PB may relate to the same revision status as publication PA, that means it will only differ with respect to the publisher (here A and B) if, for example, entity B accepts all revisions1:1from entity A with regard to entity X, or the publication PB contains or already refers to a new revision status, i.e. it differs from publication PA also in terms of content if, for example, entity B accepts the revision status from entity A with regard to entity X and adds its own revision before publication.

The following table shows examples for entity A according toFIG.9, which publishes/provides publications/revision statuses including data/information relating to entity X for the entity B on the occasion of particular events.

Publication withEventregard to entity XEntity AEntity BCompletion ofcircuit diagramelectronicsdispatcherdesignengineer(procurement)Completion ofswitch cabinetmechanicaldispatcherdesign3D modelengineer(procurement)Device tested andpower supplyguidance systemcommissioningserial numberunit device withon production lineengineergeneratedserial number21751T0352Completion ofpower supplycommissioningservice staffparameterizationunit device withengineermemberserial number21751T0352Modification ofpower supplyservice staffservice staffparameterizationunit device withmembermemberserial number21751T0352

FIG.10illustrates the procedure of a revision proposal with subsequent revision acceptance (see alsoFIG.8). This allows modified information about an entity X to be forwarded from an entity A to an entity B. A precondition is that entity B has already derived a publication PB that relates to entity X. This publication PB may, for example, have been generated by a previous publication derivation20(see alsoFIG.9). Entity A now creates a new publication PA2, which again relates to entity X and contains or refers to a new revision status. Entity A now proposes to the entity B the new revision status or the name assigned to this revision status of publication PA2, as a revision proposal. The proposal is transmitted to entity B via the network19or via some other communication channel. Since the network is configured as a decentralized distributed storage system based on blockchain technology, the proposal is made available in the form of a transaction (permanent message) which in particular contains the address of the sender or publisher, the address of the recipient, the address of the entity to which the revision status relates, and the address or name of the revision status (e.g. “master” or “dev”).

There are various ways how a recipient can find out about the existence of a new revision proposal. For example, he or she may actively search for existing revisions, “on demand”. Alternatively, the recipient can be automatically notified, “on subscription”, by subscribing to revisions that arrive in the system. Or, the sender or publisher of the revision proposal contacts the recipient on a communication channel external to the system, for example by messenger, e-mail, telephone, letter.

After a revision proposal has been made, entity B decides whether the revision proposal should be accepted or rejected. If the revision proposal of publication PA2is intended to be rejected, no further interaction will take place. However, if the proposed revision is intended to be adopted, entity B generates a new publication PB2, which either merges the revision status from PB and PA2by referring to both of them or accepts the revision status of PA2by only referring thereto.

In order to actively search for existing revision proposals or revision statuses that represent a revision proposal, the recipient may, for example, search the blockchain or the blockchain storage system for transactions that contain information with respect to a revision status addressed to the recipient and/or relating to the entity. On the one hand, this is possible because the transactions preferably also contain, stored therein as part of the transaction data, the addresses of the sender and of the recipient, i.e. their public keys or the first hash values generated on the basis thereof. On the other hand, there may be transactions in which the addresses of revision statuses (or data objects) and of entities are stored for the purpose of mutual association. The names of revision statuses may also be stored in transactions. For example, the recipient may search through a list of transactions in the blockchain or an indexing structure derived therefrom, such as the so-called Event Logs in the case of the blockchain service platform Ethereum. Once the recipient has determined a transaction, he or she will then also know the sender of the revision proposal. Thereafter, the recipient will receive the data object addressed in the transaction and decrypt it if necessary. The recipient can now compare the content of the revision status of the data object, that is, the revisions proposed by the sender, with another revision status available with the recipient. The names optionally assigned to the revision statuses facilitate a targeted inspection or comparison of a plurality of revision statuses. If the recipient wants to accept the proposed revision, he or she can merge the two revision statuses and generate a new revision status.