Method and system for securely providing data of a principal throughout its lifetime
By generating asymmetric key pairs and hash values for each entity, and combining distributed storage and blockchain technology, the problems of data security and traceability in cross-organizational PLM systems are solved, and cross-organizational data management and auditability are achieved.
Patent Information
- Application Number
- CN202080027637.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2019-04-09
- Filing Date
- 2020-04-03
- Publication Date
- 2025-11-25
- Estimated Expiration
- 2040-04-03
AI Technical Summary
Existing PLM systems struggle to operate across organizations and cannot achieve cross-organizational data authentication, authorization, collaboration among multiple stakeholders, data change processes, status change marking, status change release, confidentiality, integrity, availability, authenticity, accountability, and auditability.
Asymmetric key pairs are used to generate public and private keys for each entity, and hash values are generated through cryptographic hash functions. The distributed content addressing storage system and blockchain technology are used to store and manage the entity's data, ensuring data security and traceability.
It implements a cross-organizational PLM system, ensuring clear identification and naming of data, ensuring data integrity and security, providing a flexible, scalable, and fault-resistant data storage solution, and supporting cross-organizational auditability and traceability.
Smart Images

Figure CN114072783B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to a method for securely providing a subject's data throughout its entire lifecycle, and a system for performing the method. Background Technology
[0002] The product lifecycle of electrical products and their combinations extends across multiple organizational units in a networked manner. Guideline VDI / VDE 2182 describes the interrelationships between those who create automation solutions, machine manufacturers and system integrators, and operators of production and process equipment. This guideline follows a risk-based approach, which first refers to the automation solution as the observer. This observer experiences different lifecycle phases (manufacturing, integration, operation). It should be noted that these lifecycle phases are not necessarily limited to a single organization.
[0003] Product Lifecycle Management (PLM) is a concept for the integrated aggregation of all data generated throughout a product's lifecycle. The core functionality of a PLM system is product structuring and document management. These functions more or less strictly adhere to overlapping methodological models for configuration management (e.g., CMII, ANSI 649, ISO 10007). Configuration management includes methods for managing configuration objects (so-called Configuration Items):
[0004] • Identification and naming of configuration objects,
[0005] • Identification of configuration changes
[0006] • Release of configuration changes
[0007] • Configuration auditing.
[0008] Therefore, PLM is actually a cross-organizational process and requires models for identity, change of state, release, and auditability.
[0009] However, traditionally, PLM is operated from the perspective of a single organization and implemented within its IT systems. For example, pioneering conventional PLM solutions include Siemens Teamcenter or the ARAS PLM platform. These offerings are tailored to enterprises looking to improve their PLM processes. The implementation scope of the system technology ranges from field installations to cloud installations. In field installations, the entire PLM system runs on the enterprise-side infrastructure within the user's company; in cloud installations, it runs on centrally hosted infrastructure on the Internet. The aforementioned methods for managing configuration objects are implemented through conventional PLM solutions, for example, as follows:
[0010] • Identification and naming of configuration objects: Configuration objects are identified by user-defined or automatically prefixed strings (e.g., part numbers). Users are identified by usernames and authenticated with passwords. This information is managed within the enterprise's internal identity management system (e.g., Microsoft Active Directory).
[0011] • Identification of configuration changes: Changes to configuration objects are identified by sequential numbering (change index).
[0012] Release of configuration changes: Authorize access to configuration objects within the enterprise based on Role-Based Access.
[0013] Therefore, system support for PLM processes across organizations fails because implementation of aspects such as authentication and authorization, status change tagging, and data change processes varies across organizations. Thus, it is clear that configuration auditing can also be performed without crossing organizational boundaries.
[0014] Therefore, modern PLM requires models for identification, status change, release, and auditability, which can also be implemented across organizations or enterprises.
[0015] Current trends are often described with keywords such as "Industry 4.0" or "Internet of Things" (IoT), and the outlook for these trends makes the need for PLM (Product Lifecycle Management) across organizations even more urgent.
[0016] Two tools, the "Industry 4.0 Reference Architecture Model" (RAMI 4.0) and "Industry 4.0 Components," developed by the Industry 4.0 platform, provide an overview of existing standards and technologies. A novel aspect of the Industry 4.0 Components is the extension of the corresponding physical entities around a management shell (Verwaltungsschale). The management shell is a virtual mapping of the physical entity and describes its functionality. Therefore, Industry 4.0 Components can be self-describing and carry all datasets throughout their lifecycle. Industry 4.0 compliant communication also occurs through the management shell of the Industry 4.0 Components. Products and production facilities designed as Industry 4.0 Components can communicate with each other both within a factory and across enterprises. Summary of the Invention
[0017] The purpose of this invention is to provide a method and system for securely providing a subject's data throughout its entire lifecycle, enabling PLM operations across organizations.
[0018] Within the scope of this invention, the product or configuration object is also referred to as the subject. The invention is described below using products and production facilities in the field of automation technology as examples. However, in principle, the invention can realize PLM for cross-organizational operations for any subject.
[0019] Field devices are a key component in automation technology, used in industrial equipment, process automation, and production automation. In principle, any device that is located close to the process and provides or processes process-related information is called a field device. Therefore, field devices are used to detect and / or influence process variables. Measuring devices or sensors are used to detect process variables. Actuators are used to influence process variables. In modern industrial equipment, field devices are typically connected via communication networks, such as fieldbuses. Fieldbus, (etc.) connects to a higher-level unit. Typically, the higher-level unit is a control unit, such as an SPS (programmable logic controller) or a PLC (programmable logic controller). Furthermore, the higher-level unit is used for process control as well as for starting, configuring, and parameterizing field devices.
[0020] In industrial applications, configuration is performed on multiple devices within an automated network. Here, the integrity, validity, and source of the configuration data must be verified. For example, it must be ensured that the configuration data contains tamper-proof parameters, intact programs, or matching configurations to meet, for example, safety or security requirements.
[0021] Publication DE 10 2016 118 614 A1 describes a method for tamper-proof storage of data from field devices when using blockchain technology.
[0022] The published document DE 10 2016 215 915 A1 describes a method for securely configuring devices when using blockchain technology.
[0023] However, no solution for PLM operations across organizations can be derived from the aforementioned prior art.
[0024] In achieving the above-mentioned objectives of the present invention, the following aspects are also preferably considered:
[0025] • Certification
[0026] • Authorization
[0027] • Collaboration among multiple activists
[0028] • The process of changing data
[0029] • Change the status flag,
[0030] • Release of changed state
[0031] • Confidentiality:
[0032] Data can only be read or modified by authorized users; this applies both to accessing stored data and during data transfer.
[0033] • Integrity:
[0034] Data must not be altered without being noticed. All changes must be understandable;
[0035] • Availability:
[0036] To prevent system failures, access to data must be guaranteed within the agreed timeframe.
[0037] • Authenticity:
[0038] It represents the authenticity, verifiability, and credibility of a subject;
[0039] • Binding / Non-repudiation:
[0040] The actions performed cannot be denied without permission;
[0041] • Accountability:
[0042] The actions performed can be explicitly mapped to communication members;
[0043] • Auditability:
[0044] Compliance with the foregoing can be demonstrated relative to a third party.
[0045] To achieve the above objectives, the present invention particularly provides a method having the features of claim 1 and a system having the features of independent claim 21. Other advantageous designs of the method and system according to the invention are given in the dependent claims. Hereinafter, the features and advantages described with respect to the method of the invention also apply, in a sense, to the system of the invention.
[0046] Therefore, a method is proposed for securely providing a subject's data throughout its entire lifecycle, wherein each subject is represented by a corresponding entity that enables cryptographic identification of the entity by generating an asymmetric key pair, including a public key and a private key, for each entity, and assigning a unique address to the entity. The method further includes the following additional steps:
[0047] -a) Generate data relating to the subject.
[0048] -b) Generate a second hash value based on the data from step a) using a cryptographic hash function.
[0049] -c) generates a status change.
[0050] -d) Store the data from step a) and the second hash value in the changed state from step c) as user data (Nutzdaten), especially the user data of the changed state.
[0051] -e) Generate a third hash value based on the changed state using a cryptographic hash function, where the third hash value is used as the address of the changed state.
[0052] -f) generates a data object.
[0053] -g) Store the changed state and third hash value in the data object from step f).
[0054] -h) Store the data object in a distributed, content-addressable storage system.
[0055] The method according to the invention has many advantages. Therefore, it provides explicit and reliable identification and naming of configuration objects that can be referred to as subjects. Furthermore, it provides explicit and reliable identification and naming of configuration changes (change states), i.e., based on hash values. The hash values also ensure the integrity of the subject's data. Moreover, compared to centrally hosted PLM systems, distributed content-addressed storage systems are more flexible, easier to scale, have higher performance, are readily available, and are more fault-tolerant. In this way, the method implements a PLM that can operate across organizations and thus, practically, throughout the entire product lifecycle.
[0056] Here, the subject's data can be all data relating to the subject throughout its lifecycle, data generated before, during, and / or after its manufacture and which should continue to be prepared. Here, the subject can be a product or manufacturing facility, equipment, machine, component, software, or, generally speaking, an object. Generating this data in step a) can here mean generating new and / or modified data.
[0057] Each entity, whether self-contained or specific, represents a subject, constituting a virtual mapping of that subject, which describes the subject using data. Therefore, given RAMI 4.0, entities essentially correspond to the management shell of Industry 4.0 components. In data modeling, objects that should be uniquely identified are called entities, about which information should be stored and processed. Objects can be material or immaterial, concrete or abstract.
[0058] There are various possibilities for associating a subject with an entity representing the subject. For example, the private and / or public keys of the entity's asymmetric key pair and / or the entity's address can be stored in the subject's storage module, where the storage module is in particular a secure hardware module, such as a Trusted Platform Module (TPM). Alternatively, the entity's address can be optically detected on the subject's surface, especially as a QR code, or as a Uniform Resource Identifier (URI) or the like. However, here, for example, the first hash value used as the address does not need to be stored at all, since it can always be derived from the public key.
[0059] An improved version of this method stipulates, for example, that the entity's public key or a first hash value is used as the entity's address, the first hash value being generated based on the entity's public key using a cryptographic hash function. Therefore, this method provides a clear and reliable identification and naming of the configuration object, i.e., the subject, based on the public cryptographic key or hash value. Here, the first hash value has the advantage of being significantly shorter than the public key. However, in principle, the public key can also be used as the address.
[0060] Another improvement to the method, for example, specifies that the data relating to the subject specifies the characteristics of the subject. For example, such data can describe the characteristics and functions of the subject. For example, it can be device configuration information, which may include, for example, planning parameters, operating mode information, licensing or authorization information, security zone information, patch information or software update information, and rules for permitted configuration settings. For example, thresholds or adjustment parameters are given as planning parameters. Furthermore, it advantageously includes availability or release information for software code, patches, or firmware, such as execution rights or license information on a specific device or device type. Other examples of data relating to the subject are manuals, circuit diagrams, and CAD drawings. Therefore, the data of the subject can advantageously be substantially arbitrary data.
[0061] Another improved version of the method specifies that the data involving the subject stored in the changed state is hierarchically structured into files and folders, wherein at least one file hash value and / or folder hash value is generated progressively from the lowest level to the highest level based on the number of existing files and / or folders. Here, for each file, a file hash value is generated based on its file content using a cryptographic hash function. Furthermore, for each folder containing only multiple files, a folder hash value is generated based on the file name and file hash value of the files contained within the folder using a cryptographic hash function. Additionally, for each folder containing only multiple folders, a folder hash value is generated based on the folder name and folder hash value of the folders contained within the folders using a cryptographic hash function. Furthermore, for each folder containing multiple folders and multiple files, a folder hash value is generated based on the folder name and folder hash value of the folders contained within the folders, and based on the file name and file hash value of the files contained within the folders, using a cryptographic hash function. Finally, a second hash value is generated in step b) using a cryptographic hash function based on the folder name and folder hash value of the folder existing at the highest level and / or based on the file name and file hash value of the file existing at the highest level.
[0062] Therefore, advantageously, the subject's data can have arbitrarily complex structures without compromising the security of the available data, particularly its integrity. Here, for example, the data involving the subject can be structured as files and folders, referencing other change states, based on the data model of the version control system Git.
[0063] Another improvement to the method specifies that, in step d), in addition to user data, the changed author, change date, change time, changed description text, and / or data volume value are also stored as additional data in the change status generated in step c). This additional data can be stored, in particular, as metadata of the change status. Therefore, advantageously, this additional data or metadata regarding the change status, especially regarding each change status, is directly available and thus allows, for example, a rapid assessment of the included data based on timeliness or importance.
[0064] Another improvement to the method, for example, is specified for the correspondence between entities and changed states, in step d), in addition to user data, to store the address of at least one entity as additional data in the changed state generated in step c). Another possibility for the correspondence between entities and changed states will be described below.
[0065] In another improvement to the method, a name is generated for the change status in step g), and this name is associated with the change status and stored in the data object generated in step f). This name can be a verbal description of the change status, such as "Installation Status," "Planned Status," or "Version 1.0," which is easier for users to understand and more readily apparent than a hash value. This makes it easier to selectively browse or compare multiple change statuses, for example, when suggesting and adopting changes, especially since the "most up-to-date" change status is not always important or necessary.
[0066] Another improvement to this method specifies that, in step d), in addition to user data, the third hash value of an older changed state or multiple third hash values of older changed states are stored as additional data in the changed state from step c). This additional data can therefore also be reference data or address data used as a reference or pointer. This simple approach allows for the establishment of associations with older changed states. Here, the data of the new changed state supplements or rewrites the data of the older changed states. This yields other advantages. On the one hand, storage space is saved because the new changed state does not need to contain the unchanged data of the associated older changed states itself, but only references the unchanged data. On the other hand, the history of changed states can therefore be established or understood in a simple manner.
[0067] Another improvement to the method specifies that the lifecycle of a subject does not begin with its manufacture, but rather begins before that, whereby the subject exists as a subject type (i.e., alive or constituted) before its manufacture and then exists as at least one subject instance upon the commencement of its manufacture. It is also specified that each subject instance is derived from a subject type, and each subject type and each subject instance is represented by its corresponding entity. Furthermore, then in step d), in the changed state generated in step c) of the newly derived subject instance, a third hash value of the subject type's changed state is stored as additional data in addition to user data. Here, the number of subject instances corresponds to the number of manufactured items. Examples of subject types and subject instances are illustrated in the description of the embodiments. Through the derivation of a subject type, a subject instance can adopt or inherit data relating to the subject type. This is done in the subject instance's changed state based on its hash value, in association with the subject type's changed state. In this simple and advantageous manner, the changed state of a subject type can be used to provide a unified data foundation, and for each subject instance derived from that subject type, the data contained in that changed state of the subject type can be adopted, either fully or partially. Here, for example, data of the subject type can be partially adopted into the subject instance in the following way: that is, the selected data is copied from the change state of the subject type to the change state of the subject instance.
[0068] Furthermore, for example, it is possible that a subject type has multiple parallel change states, each comprising a different but currently existing subset of data, with each change state assigned a different name. Here, each of these parallel change states may, for example, correspond to a production variant with specific characteristics. A subject instance derived from such a subject type with multiple parallel change states appropriately adopts or inherits data from only one of the parallel change states of the subject type; that is, in the change state of that subject instance, in addition to user data, a third hash value from one of the parallel change states of the subject type is stored as additional data. Thus, this is another example of partially adopting data from a subject type into a subject instance.
[0069] An improved version of this method specifies that, in step d), the change state of the existing subject instance generated in step c) stores, in addition to user data, a third hash value of the new change state of the subject type as supplementary data. In this simple and advantageous manner, changes or updates (such as firmware updates) can be provided as a new change state of the subject type, and for each subject instance derived from that subject type, the data contained in that new change state of the subject type can or should be adopted. This is done by associating the new change state of the subject type with its hash value in the new change state of the subject instance.
[0070] An improved version of this method specifies that, in step d), the change state of the subject type generated in step c) stores, in addition to the user data, a third hash value of the change state of another subject type, or multiple third hash values of the change states of other subject types, as supplementary data. In this simple and advantageous manner, data for complex combinations or modularly constructed subjects can also be provided. For example, a subject instance derived from such a combination of subject types can then adopt or inherit data from all associated subject types. However, a subject instance derived from such a combination of subject types can also adopt or inherit data from only a few associated subject types. Thus, this is another example of partially adopting data from subject types to subject instances.
[0071] In cases where subject instances should be spontaneously and especially one-timely formed when building a single machine, but there is no corresponding subject type for the combination, the third hash value of the change state of another subject instance or the third hash value of the change state of multiple other subject instances can be used as additional data storage in the change state of that subject instance, in addition to user data.
[0072] An improved version of this method specifies that the distributed, content-addressable storage system is constructed based on the InterPlanetary File System (IPFS).
[0073] An improved version of this method stipulates that the personnel involved in the method are also represented by their own entities. Here, the entity representing the person can also be cryptographically identified by generating an asymmetric key pair including a public key and a private key for that entity. Furthermore, the entity representing the person can be assigned an address, specifically a unique address. Here, the entity's public key or a first hash value, generated using a cryptographic hash function based on the entity's public key, can be used as the entity's address. Therefore, the corresponding improved method also provides explicit and reliable identification and naming of personnel, especially users, based on public cryptographic keys or hash values. Moreover, the data of the personnel involved can be provided in substantially the same manner as the data of the subjects involved.
[0074] For storing private and / or public keys to asymmetric key pairs and / or the address of the entity representing the person, various possibilities exist, where the first hash value can always be derived from the public and therefore does not need to be stored. For example, it can be stored in a storage module owned by the person, such as a Trusted Platform Module (TPM) or a USB token. Here, read and write access to the storage module can be additionally protected using a PIN or password. Alternatively, it can be stored in an authentication system, particularly within an enterprise, such as Active Directory or Kerberos, where usernames and passwords are advantageously used to secure read and write access to the authentication system. Alternatively, storage can also be achieved by expressing the key as text, especially in hexadecimal, on paper, or as a QR code, especially a Uniform Resource Identifier (URI), or similar, owned by the person.
[0075] According to another improved version of the method, after storing the changed state and, if it exists, the name and / or third hash value corresponding to the changed state in step g), the data object is encrypted with a randomly generated symmetric session key, so that the data object containing the changed state and its corresponding third hash value and possible name exists as a fully encrypted data object.
[0076] In this regard, another improvement to the method specifies that, in step g), after the encryption change state, the symmetric session key is encrypted using the asymmetric public key of the intended recipient, in particular the entity set as the recipient.
[0077] The advantage of this is that it now also ensures the confidentiality of changes made to the data of the subject, or subject type or subject instance.
[0078] In another improved version of this method, step g) is specified to finally generate a fourth hash value based on the data object using a cryptographic hash function, where the fourth hash value is used as the address of the data object. This can be done for both unencrypted and encrypted data objects.
[0079] The fourth hash value enables explicit addressing and retrieval of corresponding data objects in a distributed, content-addressable storage system. However, decrypting the encrypted data object requires an appropriate symmetric session key. The intended recipient may, for example, have obtained the appropriate symmetric session key encrypted with their asymmetric public key via email. Using their asymmetric private key, the recipient can decrypt the encrypted session key and then use it to decrypt the encrypted data object.
[0080] According to an improved version of this method, a persistent notification, particularly a transactional notification, is generated for the changed state stored in step g), and this notification is stored in a decentralized, blockchain-based storage system (hereinafter referred to as the blockchain storage system). Here, the blockchain storage system specifically stores at least one data block, which includes data content and a hash value, wherein the hash value is generated based on the data content of the data block using a cryptographic hash function and is used as the address of the data block. The method according to this improved version includes the following additional steps:
[0081] -i) generates a transaction.
[0082] -j) Store the fourth hash value as part of the transaction data in the transaction from step i), and thus associate the transaction with the data object from step h), with the changed state stored within that data object.
[0083] -k) generates data blocks.
[0084] -l) Store the transaction as data content in the data block from step k).
[0085] -m) determines the fifth hash value, which is the hash value of the data block last stored in the blockchain storage system.
[0086] -n) Store the fifth hash value as data content in the data block from step k).
[0087] -o) Generate a hash value for the data block based on its data content using a cryptographic hash function, wherein the hash value is used as the address of the data block.
[0088] -p) Store the hash value generated in step o) into the data block, and
[0089] -q) Stores data blocks in a blockchain storage system that also stores data blocks created at an earlier point in time.
[0090] The data content therefore includes the transactions stored in the data block, specifically all transactions stored in the data block, as well as the hash value of the last data block stored in the blockchain storage system. By storing the hash value of the last data block stored in the blockchain storage system in the data content of the newly generated data block, the association or linking of data blocks is achieved, where each data block is always associated or linked with previously stored data blocks, thus gradually creating a continuously growing chain of data blocks.
[0091] Therefore, changes to data concerning a subject, subject type, or subject instance are recorded in a simple, advantageous, immutable, and durable manner. In particular, when timestamps are also stored in data blocks, the points in time when changes are made are advantageously recorded in an immutable, durable, and undeniable way.
[0092] Just as the first storage system used to store changes in state is similar to the second storage system, which is based on blockchain technology and used to store notifications of these changes in transactional form, it is also constructed as a distributed storage system. Therefore, it similarly offers the advantages mentioned above: flexibility, scalability (i.e., system capacity can be easily matched to data volume, transaction volume, and user volume), availability, and fault tolerance. Consequently, it is equally suitable for PLM across organizations. Here, the first and second storage systems are two essentially independent storage systems. The additional storage of persistent notifications of changes in state further provides the advantage that even if the changed state is no longer available in the first storage system, the notification stored in the second storage system always confirms that the changed state existed. Here, the blockchain-based storage system can be provided, in particular, through a blockchain service platform such as Ethereum.
[0093] In another improvement to this method, it is specified that in step j), the encrypted session key is stored as another part of the transaction data in the transaction from step i). Thus, while the encrypted session key in the blockchain storage system is accessible to every interested recipient, only the intended recipient can decrypt the encrypted session key again using their asymmetric private key and subsequently decrypt the encrypted changed state using the session key. The data object storing the encrypted changed state can be explicitly addressed and accessed in a distributed, content-addressed storage system based on a fourth hash value stored in the transaction along with the encrypted session key.
[0094] Preferably, the method further specifies that, in step j), a signature is additionally stored as part of the transaction data in the transaction generated in step i), wherein the signature is a value, in particular a numerical value, representing the initiator of the transaction, which is generated using an asymmetric cryptographic function based on a fourth hash value and the initiator's, in particular the entity regarded as the initiator's, asymmetric private key.
[0095] This signature offers several other advantages. By storing signatures in transactions, these signatures can be verified decentralizedly. This adapted approach also provides accountability, binding force, and non-repudiation for changes made to data concerning a subject, subject type, or subject instance, stored as a change state, thus improving integrity and authenticity. This is also highly advantageous in terms of auditability, that is, provability relative to third parties, as the initiator can be proven for each signed change state.
[0096] A transaction that has a signature and references a specific changed state can also reliably constitute the release of that changed state, for example. Here, the recipient can decide whether to grant permission to release the changed state to the initiator, whose signature can be verified.
[0097] If it is stipulated that transactions without signatures should not be stored in principle, then write authorizations that can be reliably verified in a decentralized manner can also be constructed, for example.
[0098] Furthermore, this method can advantageously stipulate the generation and storage of transactions for other purposes within the blockchain storage system. For example, in a transaction, the entity's address (specifically, the first hash value) and the address of the changed state (the third hash value) can be stored as transaction data to correspond entities and changed states to each other. As an alternative or supplement to the address of the changed state, the address of the data object containing the changed state (the fourth hash value) can also be stored as part of the transaction data. The name corresponding to the changed state can also be stored as part of the transaction data if necessary. Thus, any number of changed states can be assigned to an entity, and any number of entities can be assigned to a changed state. To avoid having to generate and store a separate transaction for each entity-changed state correspondence, multiple entity addresses along with the address of the same changed state, or multiple changed state addresses along with the address of the same entity, can be stored in a single transaction.
[0099] Another improvement to this method specifies that steps a) to g) or a) to q) are performed by the subject instance. This will be discussed in detail later in conjunction with the system according to the invention.
[0100] Furthermore, an improved version of the method specifies that method steps a) to g) or a) to q) are repeatedly performed as needed or according to events. Advantageously, when there is innovation or change in the data regarding the subject or subject type or subject instance, that is, when there are multiple innovations or changes for each subject type or subject instance, the corresponding method steps can be implemented, for example, always.
[0101] Furthermore, a system is proposed, configured to implement the method according to the invention, particularly including at least one of its optional improvements, to securely provide the subject's data throughout the subject's entire lifecycle. Here, the system includes a communication network with at least two user nodes, each user node having a storage device and a processing device, as well as a communication device for coupling to and communicating through the communication network. Here, the subject's data can be stored in the storage device and provided to at least one other user node in the communication network via the communication device. Furthermore, machine-executable program code is stored in the storage device, which, when executed by the processing device, causes the provision of the subject's data according to any one of the preceding claims. Additionally, the system itself is configured as a distributed content-addressed storage system, or the system is part of a higher-level system configured as a distributed content-addressed storage system, or the system is connected to a distributed content-addressed storage system, for example, via one of the user nodes. Additionally, the system itself can be configured as a distributed blockchain-based storage system (blockchain storage system) or as part of a higher-level system configured as a blockchain storage system, or connected to a blockchain storage system, for example, via one of the user nodes.
[0102] The features and advantages previously described for the method and its alternative improvements are similarly applicable to the proposed system.
[0103] When a subject or subject instance is, for example, a device or machine, and that subject instance has storage, processing or computing, and communication devices, it can be configured to autonomously or automatically implement the steps of the method according to the invention. That is, such a subject instance can securely provide data, particularly data relating to it, according to the invention. Here, the subject instance itself can be configured as a user node in the communication network of the system according to the invention, or particularly due to its limited computing and / or storage capacity, it is in a communication connection with a user node. Importantly, the entity representing the subject instance, particularly the private key of the entity's asymmetric key pair, is retained in the subject instance, so that the subject instance can sign the provided data, such as changed status or changed network address. Attached Figure Description
[0104] These and other features, as well as many advantages, of the invention also become apparent from the embodiments described in more detail below with reference to the accompanying drawings. The drawings are shown herein.
[0105] Figure 1a An exemplary construction of the method from steps a) to h) is illustrated schematically in the form of a simple flowchart;
[0106] Figure 1b An exemplary construction of the method from step i) to q) is illustrated in the form of a simple flowchart;
[0107] Figure 2 A schematic diagram illustrating an exemplary construction of the system is shown;
[0108] Figure 3 The four basic premises for the operation of the method according to the present invention are illustrated in the diagram.
[0109] Figure 4 The identity model, which is a basic premise, is illustrated in the diagram.
[0110] Figure 5 The content model, which is a basic premise, is illustrated in the diagram.
[0111] Figure 6 The diagram illustrates a distributed model for write authorization, which is a fundamental prerequisite.
[0112] Figure 7 The diagram illustrates a distributed model for read authorization, which is a fundamental prerequisite.
[0113] Figure 8 The interaction model, which is based on the fundamental premise, is illustrated in the diagram.
[0114] Figure 9 The process of deriving the product information is illustrated in the diagram.
[0115] Figure 10 The flowchart illustrates the process of change proposals with subsequent change adoption. Detailed Implementation
[0116] exist Figure 1a and Figure 1b The diagram illustrates exemplary method steps a) to q) for a method of securely providing subject data throughout the subject's entire lifecycle, which are executed sequentially. In this case, a connection symbol represented as "1" in a circle is formed. Figure 1a Method steps h) and Figure 1b The connection between method steps i) in the process.
[0117] It is assumed here that the lifecycle of a subject does not begin with its manufacture, but rather predates it, wherein the subject exists as a subject type before its manufacture and then exists as at least one subject instance upon the commencement of its manufacture, wherein each subject instance is derived from the subject type, and wherein each subject type and each subject instance is represented by a corresponding self-entity. Here, the number of subject instances thus corresponds to the number of units manufactured. By deriving the subject type, a subject instance can receive or inherit at least a portion of the data associated with the subject type.
[0118] Now, let's examine this method in detail for a newly manufactured subject example.
[0119] However, before proceeding to step a), an entity representing the subject instance must first be generated, enabling cryptographic identification of the entity by generating an asymmetric key pair comprising a public and a private key, and, for example, enabling the entity to be addressed by a first hash value generated using a cryptographic hash function based on the entity's public key. Here, the method includes the following additional steps:
[0120] In step a), data about the subject instance and that should be provided is generated. This could be, for example, all data specifying the characteristics of the subject instance or describing the properties and / or functions of the subject instance. In any case, this data is then hierarchically structured into files and folders.
[0121] In step b), a second hash value is generated based on the data from step a) using a cryptographic hash function. For this purpose, at least one file hash value and / or folder hash value is generated sequentially from the lowest level to the highest level, based on the number of existing files and / or folders. Here, for each file, a file hash value is generated based on its file content using a cryptographic hash function. Furthermore, for each folder containing only multiple files, a folder hash value is generated using a cryptographic hash function based on the file names and file hash values of the files contained within the folder. Additionally, for each folder containing only multiple folders, a folder hash value is generated using a cryptographic hash function based on the folder names and folder hash values of the folders contained within the folders. Furthermore, for each folder containing multiple folders and multiple files, a folder hash value is generated using a cryptographic hash function based on the folder names and folder hash values of the folders contained within the folders, and based on the file names and file hash values of the files contained within the folders. Finally, a second hash value is generated based on the folder names and folder hash values of the folders existing at the highest level and / or based on the file names and file hash values of the files existing at the highest level.
[0122] A new change state is generated in step c).
[0123] In step d), the data generated in step a) and the second hash value generated in step b) are stored as user data in the changed state generated in step c). Additionally, in this example, the entity's address is additionally stored as additional data in the changed state from step c) to associate the new changed state with the entity. Thus, the changed state and its content are associated with the entity. Furthermore, in the changed state from step c), in addition to user data, a third hash value of the changed state of the subject type is also stored (in...). Figure 1a (Not shown in the image), and thus establishes an association with that change state. Then, if necessary, the data of the new change state of the subject instance supplements or rewrites the data of the old change state of the associated subject type. In addition, the change state from step c) stores, in addition to user data, the change author, change date, change time, change description text, and data volume value, especially as metadata of the change state, where metadata is also supplementary data.
[0124] In step e), a third hash value is generated based on the changed state using a cryptographic hash function. Here, not only user data but also any additional data stored in the changed state is considered. The third hash value is then used as the address of the changed state.
[0125] In step f), a new data object is created, which is configured to be stored in a distributed, content-addressed storage system that can be constructed according to the InterPlanetary File System (IPFS).
[0126] In step g), a name is generated for the changed state and associated with it. The name can be, for example, a tag or version number, which is particularly easy for the user to understand. Here, the association can be done, for example, by associating the name with a third hash value used as the address of the changed state. The changed state, the third hash value, and the name are then stored in a data object from step f). Next, the data object containing the changed state, the third hash value, and the name corresponding to that changed state is encrypted using a randomly generated symmetric session key. After encrypting the data object, the symmetric session key is encrypted using the intended recipient's asymmetric public key. Furthermore, a fourth hash value is generated based on the data object using a cryptographic hash function, where the fourth hash value is used as the address of the data object.
[0127] Finally, in step h), the data object is stored in a distributed, content-addressable storage system.
[0128] Furthermore, a persistent notification in the form of a transaction should be generated for the changed state stored in step g) and stored in a decentralized, blockchain-based storage system (blockchain storage system). At least one data block, comprising data content and a hash value, has already been stored in the blockchain storage system. This hash value is generated based on the data content of the data block using a cryptographic hash function and serves as the address of the data block. If a data block is actually stored first in the blockchain storage system, this is called the genesis block, which represents the first data block of the blockchain and is the only data block, regardless of previous data blocks. However, other data blocks may also already be stored in the blockchain storage system. Therefore, the following additional steps are set up:
[0129] In step i), a new transaction is generated, which should function as a persistent notification of the changes to the state storage made in step g).
[0130] In step j), the fourth hash value is stored as part of the transaction data from step i), and thus the new transaction is associated with the data object from step h) in which the changed state is stored. Additionally, the current timestamp is generated and stored as part of the transaction data (in...). Figure 1b (Not shown in the image). Furthermore, the encrypted session key from step g) is stored as an additional part of the transaction data in the transaction from step i). Additionally, the signature ( Figure 1b (Not shown) is stored in the transaction as part of the transaction data, where the signature is a digital value representing the initiator of the transaction, generated using an asymmetric cryptographic function based on a fourth hash value and the initiator's asymmetric private key. In another example (not shown), other parts of the transaction data may be additionally considered when generating the signature.
[0131] Then, in step k), data blocks are generated according to blockchain technology.
[0132] In step l), the transaction is stored in a data block.
[0133] In step m), the fifth hash value is determined, which is the hash value of the last data block stored in the blockchain storage system.
[0134] In step n), the fifth hash value is stored as part of the other data content in the data block from step k).
[0135] In step o), a hash value for the data block is generated. More precisely, a hash value for the data block is generated based on the data content of the data block using a cryptographic hash function, where the hash value is used as the address of the data block.
[0136] In step p), the hash value generated in step o) is stored in the data block.
[0137] In step q), the data block is stored in the blockchain storage system, which also stores data blocks created at earlier points in time. Therefore, changes in state are recorded in the blockchain or the blockchain storage system.
[0138] In another, in Figure 1a and Figure 1b In an exemplary embodiment of the method concerning a subject type (not shown), in step d), in a new change state of the subject type, a third hash value of the change state of another subject type may be stored in addition to user data, or the third hash values of the change states of multiple other subject types may be stored as additional data, thus establishing an association with these change states. This is the case if the subject type is a combination of multiple subject types or a modularly constructed subject type.
[0139] In another Figure 1a and Figure 1b In an exemplary embodiment of the method for a subject instance (not shown), in step d), in a new change state of an existing subject instance, in addition to user data, a third hash value of the subject instance's older change state may be stored as additional data, thus establishing an association with the older change state. The data of the new change state then supplements or rewrites the associated data of the older change state as necessary.
[0140] In another Figure 1a and Figure 1b In an exemplary embodiment of the method performed with respect to a subject instance (not shown), in step d), in the new change state of the existing subject instance, in addition to user data, a third hash value of the new change state of the subject type may be stored as additional data, and thus an association with the new change state of the subject type is established. This is the case if a change or update, such as a firmware update, is provided as a new change state of the subject type, which should be adopted for subject instances derived from the subject type.
[0141] Recipients who wish to read and, if necessary, further process data referenced as changed state based on persistent notifications within a blockchain storage system essentially execute these methodological steps in reverse order. The recipient thus first reads transaction data from the transaction used as a persistent notification within the blockchain storage system. Therefore, it obtains a fourth hash value addressing the data object containing the changed state, the transaction's storage timestamp, a session key encrypted with its asymmetric public key, and the signature of the transaction's initiator or publisher. The recipient can decrypt the session key using its asymmetric private key. Using the fourth hash value, the recipient retrieves the corresponding data object within the distributed, content-addressed storage system and finds the changed state encrypted with the symmetric session key, along with its corresponding name and third hash value, which it can then decrypt using the previously decrypted session key and read.
[0142] exist Figure 2 The diagram illustrates an exemplary construction of a system for executing a method used to securely provide a subject's data throughout its entire lifecycle. It includes a communication network N and four user nodes K1, ..., K4, each user node having a storage device and a processing device, as well as a communication device for coupling to and communicating through the communication network. Figure 2 Not shown in the image.
[0143] This exemplary system is configured, on the one hand, as a distributed, content-addressable storage system, wherein each of the illustrated user nodes stores data relating to a subject in its storage device, and said data can be provided to other user nodes via its communication device and communication network, particularly according to the peer-to-peer principle. On the other hand, the system communicates with other storage systems (in...) via its communication network. Figure 2 (Not further shown) The connection is used to store notifications of changes in the stored state of transactions, and the storage system is based on blockchain technology and is constructed in a decentralized manner (blockchain storage system).
[0144] Furthermore, machine-executable program code is stored in the storage device of each user node, which, when executed by the processing device of the corresponding user node, causes the provision of data to the subject involved according to the method of the present invention.
[0145] User nodes K1, K2, and K3 are related to principal instances. User node K4 is not a principal instance, but its resources, especially computing, storage, and communication resources, are provided to principal instances G1 and G2, which communicate with user node K4 due to their limited computing and / or storage capacity.
[0146] To better understand, the following uses... Figure 3Figure 11 illustrates in detail the main aspects or understanding based on the present invention.
[0147] Figure 3 The following four basic prerequisites for the operation of the method according to the invention are shown. Accordingly, identity model 1 and content model 2 are required first, distribution model 3 is based on the identity model and content model, and interaction model 4 is based on the distribution model.
[0148] exist Figure 4 The diagram illustrates an identity model based on these fundamental premises. Accordingly, there exist Person 5, (Subject) Type 6, and (Subject) Example 7, which are all entities 8, or represented by entities 8, and these entities may be equipped with data. Persons, Types, and / or Examples can act as agents to change the data of Persons, Types, and / or Examples. Here, all entities are identified through cryptographic identity 9. In the proposed method, cryptographic identity is an asymmetric cryptographic key pair 10, which consists of a publicly known key and a private key. An address 11 is derived from the publicly known key using a cryptographic one-way function (hash function), which can be used to name or address identities.
[0149] As a result of the development process, manufacturers of products (such as power supply equipment) or assembled products (such as switch cabinets) produce a type. This type represents the production procedures in digital form. As a result of the production process, manufacturers of products (such as power supply equipment) or assembled products (such as switch cabinets) produce type-based instances. These instances represent physical objects in digital form.
[0150] exist Figure 5 The content model that falls under these basic premises is illustrated. Data relating to people or subjects, or subject types or subject instances, is structured or organized into files 15, folders 14, and change states 13, which are callable by names 12 and associated with entities. In other words, entity 8 comprises a finite list of names 12, where each name points to an entity's change state 13.
[0151] For example, in the case of types, consecutive numbers, version numbers, maturity indicators, or project milestones can serve as names. In the case of instances, such as indicators of production steps, inspection cycles, or service processes, can be used as names.
[0152] The status change must include at least the author, the date of change, and the changed text (in... Figure 5 (Not shown in the image). Furthermore, the status change points to a hierarchical structure containing or organizing data in folders 14 and files 15. Files, folders, and status changes are addressable via cryptographic checksums (hash values), which are formed from the data's content using a cryptographic hash function and represent a unique and immutable master key (in...). Figure 5(Not shown in the image).
[0153] Data describes the characteristics and functions of an entity, which can be, for example, technical or commercial in nature.
[0154] Furthermore, each changed state can reference one or more previous changed states. Therefore, it maps the history of the entity's data.
[0155] Examples of data specifying a type include categorical data, drawings, circuit diagrams, data sheets, instruction manuals, product photographs, and descriptive product text. In the case of assembled products, the type may contain references to changes in the status of other types.
[0156] Examples of prescriptive data for an instance include serial numbers, test records, parameters, procedures, status data, installation locations, and installation history. In the case of assembled products, an instance may contain references to changed states of other instances. Instances may also include references to changed states of a type, upon which the instance is generated.
[0157] The table below shows an example of how to deduce an instance from a type through a procedure.
[0158]
[0159]
[0160] exist Figure 6 The diagram illustrates a distributed model regarding write authorization, which falls under these fundamental premises. Here, entities exchange data at specific points in time during an entity's lifecycle. An entity wishing to provide new or modified data is referred to as a publisher 17. A publication 18 relates to the same or another entity (e.g., type / instance) and contains a modified state 13 that should be transferred or provided. Here, data objects are referred to as publications, and these data objects are stored or provided in a distributed, content-addressed storage system.
[0161] The issuer releases the issued item by digitally signing it with their private key and transmitting it to a decentralized network 19, specifically by signing and transmitting only a hash value generated based on the data object. The decentralized network is constructed as a distributed storage system (blockchain storage system) based on blockchain technology, characterized by intertwined communicating users (user nodes) and unstructured architecture. For example, star, ring, or other structured topologies are not required to operate such a network. If the digital signature is valid, the network acknowledges the issued item and provides internal reference information.
[0162] Here, the network ensures that transactions cannot be reversed or their content altered. Furthermore, the use of digital signatures defines write authorization for the distributed model, as it stipulates that transactions without signatures are, in principle, not allowed to be stored.
[0163] exist Figure 7 The diagram illustrates a distributed model regarding read authorization, which falls under these fundamental premises. Therefore, publisher 17 also identifies one or more entities that should have read access to issue 18. These entities are the recipient 20 or the intended recipient of the issue. From the issue, the publisher forms a transport object (21) by encrypting the issue with a randomly generated session key (22). The session key is exchanged with the recipient in encrypted form using its public key. The publisher then provides the transport object across the network.
[0164] The transmitted object is addressed by its cryptographic checksum (hash value), just as before.
[0165] Therefore, the use of encryption defines the read authorization for the distributed model.
[0166] exist Figure 8 The paper illustrates an interaction model based on these fundamental premises. Based on the distributed model, the proposed interaction model provides three possible actions for interaction throughout the lifecycle.
[0167] • By inferring from the issued product 20, it is possible to generate new entities based on other issued products (see also...) Figure 9 ).
[0168] • By using suggestion 21, the publisher signals to other publishers that a change exists in the form of a new publication at the entity level, and simultaneously recommends that they adopt it (see also...). Figure 10 ).
[0169] • The other publisher may decide to change adoption 22 (see also Figure 11) or refuse to change the recommendation.
[0170] exist Figure 9 The process of deriving the issue is shown in the diagram (see also...). Figure 8 The derivation of the issue is based on the methods for reading and writing information defined in distribution model 3 (see [link to distribution model 3]). Figure 6 and Figure 7Issue derivation allows for the provision of information about entity X, and thus allows its transfer from entity A to entity B. Here, entity A first generates issue PA, which relates to entity X and contains or references changes to that entity. As the publisher of the issue, entity A identifies entity B as one of the recipients. Entity B can then read the contents of the issue. Using the existing data, entity B can derive a new issue PB. Here, issue PB can reference the same changes to issue PA; that is, for example, if entity B adopts all changes about entity X from entity A in a 1:1 ratio, the only difference being the publisher (here, A or B), or issue PB contains or references new changes; that is, if, for example, entity B adopts changes about entity X from entity A and adds its own changes before publication, then issue PB also differs in content from issue PA.
[0171] The following table shows Figure 9 The example shown is entity A, which discloses / provides to entity B a publication / changes the status of data / information about entity X for a specific event.
[0172]
[0173] exist Figure 10 The process for accepting and adopting change proposals is shown in the diagram (see also: Figure 8 This allows modified information about entity X to be transferred from entity A to entity B, provided that entity B has already derived a publication PB related to entity X. This publication PB can be generated, for example, from a previous publication derivation 20 (see also...). Figure 9 Now, entity A generates a new issuance PA2, which in turn relates to entity X and contains or references a new changed state. Entity A now proposes a new changed state from issuance PA2, or a name corresponding to that changed state, as a change proposal for entity B. This proposal is transmitted to entity B via network 19 or another communication channel. Because the network is constructed as a decentralized, distributed storage system based on blockchain technology, the proposal is provided in the form of a transaction (persistent notification), which specifically includes the sender's or publisher's address, the recipient's address, the address of the entity involved in the changed state, and the address or name of the changed state (e.g., "master" or "dev").
[0174] Recipients can be notified of new change proposals in various ways. For example, they can proactively search for existing change proposals "on-demand." Alternatively, they can be automatically notified "on-subscription" of incoming changes by subscribing to the system. Or, the sender or publisher of the change proposal can contact the recipient through external communication channels such as instant messaging, email, telephone, or mail.
[0175] After making a change proposal, Entity B decides whether to adopt or reject it. If the change proposal from issue PA2 should be rejected, no further interaction occurs. However, if the change proposal should be adopted, Entity B creates a new issue PB2 that merges the changes from both PB and PA2 by referencing the change statuses from PB and PA2, or adopts the change status from PA2 separately by referencing only the change status from PA2.
[0176] To proactively search for existing change proposals or to present the changed state of proposed changes, the recipient can, for example, thoroughly search the blockchain or blockchain storage system for transactions containing descriptions of the changed state pointing to the recipient and / or the entities involved. This is possible because the addresses of the sender and recipient, i.e., their public keys or a first hash value generated based on them, are preferably also stored as part of the transaction data. Alternatively, there may be transactions that store the changed state (or data object) and the address of the entity for mutual correspondence. The name of the changed state can also be stored in the transaction. Here, the recipient can, for example, thoroughly search the list of transactions in the blockchain or the index structure derived from it, such as the so-called event log in the case of the blockchain service platform Ethereum. If the recipient identifies a transaction, then it now also knows the sender of the change proposal. The recipient then obtains the data object at the address in the transaction and decrypts it if necessary. Now, the recipient can compare the content of the changed state from the data object (i.e., the change proposed by the sender) with other changed states existing at the recipient's location. The possible names corresponding to these changed states make it easy to selectively observe or compare multiple changed states. If the recipient wishes to accept the proposed changes, they can merge the two change states to create a new change state.
Claims
1. A method for securely providing data from a field device throughout its entire lifecycle in an automation technology field device. The lifecycle of the aforementioned field device begins before it is manufactured. The field device mentioned above existed as a field device type before its manufacture, and The field device exists as at least one instance of a field device from the start of its manufacture. Each field device instance is derived from the field device type. Each field device type and each field device instance is represented by its own entity, enabling cryptographic identification of the entity. This is achieved by generating an asymmetric key pair, including a public key and a private key, for each entity, and assigning the entity a corresponding address. The method includes the following additional steps: -a) Generate data relating to the field device type or field device instance. -b) Generate a second hash value based on the data generated in step a) using a cryptographic hash function. -c) generates a status change. -d) Store the data generated in step a) and the second hash value generated in step b) as user data in the changed state generated in step c). -e) Generate a third hash value based on the changed state using a cryptographic hash function, wherein the third hash value is used as the address of the changed state. -f) generates a data object. -g) Store the changed state and the third hash value in the data object generated in step f), and -h) Store the data object in a distributed, content-addressable storage system. In step d), when a new field device instance is derived from the field device type, the change status of the field device instance generated in step c) will also include the third hash value of the change status of the field device type as additional data storage, in addition to the user data.
2. The method according to claim 1, The address of the entity is provided by the entity’s public key or a first hash value, which is generated based on the entity’s public key using a cryptographic hash function.
3. The method according to claim 1, The data relating to the field device specifies the characteristics of the field device, and the data includes... - The characteristics and functions of the field devices, or - Device configuration information, such as planning parameters, operating mode information, license or authorization information, security zone information, patch information or software update information, or rules for permitted configuration settings, or including - For availability or release information of software code, patches, or firmware, such as execution permissions or license information on a specific device or device type, or - Manuals, circuit diagrams, and CAD drawings.
4. The method according to claim 1, The data related to field devices stored in the changed state is hierarchically structured into files and folders. Starting from the lowest level and proceeding to the highest level, at least one file hash value and / or folder hash value is generated progressively based on the number of existing files and / or folders. For each file, a file hash value is generated based on its content using a cryptographic hash function. For each folder containing only a few files, a folder hash value is generated using a cryptographic hash function based on the filenames and hash values of the files contained within the folder. For each folder containing only multiple subfolders, a cryptographic hash function is used to generate a folder hash value based on the folder names and hash values of the subfolders contained within the folder. For each folder containing multiple folders and multiple files, a folder hash value is generated using a cryptographic hash function based on the folder names and hash values of the folders contained within the folders, and the file names and hash values of the files contained within the folders. In step b), the second hash value is generated using a cryptographic hash function based on the folder name and folder hash value of the folder existing at the highest level and / or based on the file name and file hash value of the file existing at the highest level.
5. The method according to claim 1, In step d), in addition to the user data, the changed author, change date, change time, change description text and / or data volume value are also stored as additional data in the change status generated in step c).
6. The method according to claim 1, In step d), in addition to the user data, the entity's address is also stored as additional data in the changed state generated in step c).
7. The method according to claim 1, In step g), a name is generated for the changed state, and this name is corresponding to the changed state and stored in the data object generated in step f).
8. The method according to claim 1, In step d), in addition to the user data, a third hash value of an older change state or multiple third hash values of older change states are stored as additional data in the change state generated in step c).
9. The method according to claim 1, In step d), in the changed status generated in step c) of the existing field device instance, in addition to the user data, the third hash value of the changed status of the field device type is also stored as additional data.
10. The method according to any one of claims 8 and 9, In step d), in the change status generated in step c) for the field device type, in addition to the user data, a third hash value of the change status of another field device type or multiple third hash values of the change status of other field device types are also stored as additional data.
11. The method according to claim 1, The distributed content-addressable storage system described therein is constructed based on the InterPlanetary File System (IPFS).
12. The method according to claim 1, The personnel involved in the method are also represented by their own entities.
13. The method according to claim 1, In step g), after storing the changed state in the data object, the data object is encrypted using a randomly generated symmetric session key.
14. The method according to claim 13, In step g), after encryption, the symmetric session key is encrypted using the intended recipient's asymmetric public key.
15. The method according to claim 1, In step g), a fourth hash value is generated based on the data object using a cryptographic hash function, wherein the fourth hash value is used as the address of the data object.
16. The method according to claim 15, Specifically, persistent notifications are generated for the changed states stored in step g), and these notifications are stored in a decentralized, blockchain-based storage system. The distributed, blockchain-based storage system stores data blocks, each data block comprising data content and a hash value. The hash value is generated based on the data content using a cryptographic hash function and serves as the address of the data block. The method has the following additional steps: -i) generates a transaction. -j) Store the fourth hash value as part of the transaction data in the transaction from step i), and thus associate the transaction with the data object from step h), with the changed state stored within the data object. -k) generates data blocks. -l) Store the transaction as data content in the data block from step k). -m) Determine the fifth hash value, which is the hash value of the data block last stored in the distributed blockchain-based storage system. -n) Store the fifth hash value as data content in the data block from step k). -o) Using a cryptographic hash function, a hash value is generated for the data block based on its data content, where the hash value is used as the address of the data block. -p) Store the hash value generated in step o) into the data block, and -q) Store the data block in the distributed blockchain-based storage system, which also stores data blocks created at an earlier time.
17. The method according to claim 16, In step j), the encrypted session key is stored as another part of the transaction data in the transaction from step i).
18. The method according to claim 16, The method steps a) to g) or a) to q) are performed by a field device instance.
19. The method according to claim 16, The method steps a) to g) or a) to q) are repeated as needed or according to events.
20. A system for performing a method according to any one of the preceding claims for securely providing data from field devices throughout the entire lifecycle of field devices in an automation technology. The system includes a communication network (N) with at least two user nodes (K1, K2, K3, K4), each user node having a storage device and a processing device, as well as a communication device for coupling to and communicating through the communication network. The data from the field devices can be stored in the storage device and provided to at least one other user node in the communication network via the communication device. The storage device stores machine-executable program code, which, when executed by the processing device, causes the provision of data from the field device according to any one of the preceding claims. The system is configured as a distributed, content-addressable storage system.
Citation Information
Patent Citations
Method for storing data of a field device in a tamper-proof manner
DE102016118614A1
secure configuration of a device
DE102016215915A1
Internet of things blockchain interface
US20190013948A1
Compact recordation protocol
WO2018164695A1