SYSTEM AND METHOD FOR MANAGING DATA OF AN AUTOMATION FIELD DEVICE IN A SECURE MANNER AGAINST MANIPULATION

Abstract

A system for managing data of an automation field device in a secure manner includes a decentralized distributed ledger-type database, or blockchain, comprising a plurality of subscriber nodes, comprising validation-capable subscriber nodes and an automation field device with an electronic unit. The electronic unit is designed to run a distributed ledger software stack. The field device generates data, comprising measurement values and/or calibration certificates requiring verification, and the field device operates as a light node of the decentralized database after running the distributed ledger software stack and is designed to transmit the data to the decentralized database via the communication network and write said data in encrypted form into the decentralized database. The validation-capable subscriber nodes validate the transmitted data, and the decentralized database is designed to store the data if at least a specified proportion of the validation-capable subscriber nodes successfully validate the data.

Claims

1-11. (canceled)

12. A system for managing data of an automation field device in a secure manner against manipulation, comprising: a decentralized database according to the distributed ledger technology comprising a plurality of subscriber nodes comprising validation-capable subscriber nodes; an automation field device, with an electronic unit, wherein the electronic unit is designed to run a distributed ledger software stack, and with a communication interface for establishing a communication connection to the decentralized database via a wireless or wired communication network, wherein the field device is designed to generate data comprising measurement values and/or calibration certificates requiring verification, wherein the field device operates as a light node of the decentralized database after running the distributed ledger software stack and is designed to transmit the data to the decentralized database via the communication network and to write them in encrypted form into the decentralized database, wherein the validation-capable subscriber nodes are designed to validate the transmitted data, wherein the decentralized database is designed to store the data when at least a specified proportion of the validation-capable subscriber nodes successfully validates the data.

13. The system of claim 12, wherein the decentralized database additionally comprises read-authorized subscriber nodes, wherein the read-authorized subscriber nodes are designed to decrypt and read the stored data of the field device in the decentralized database.

14. The system of claim 12, wherein at least one of the subscriber nodes or a device connected to the decentralized database is designed to run an analysis program, wherein the analysis program is designed to generate alarm messages on the basis of an analysis of the measurement values of the field device that require verification and are stored in the decentralized database.

15. The system of claim 14, wherein the analysis program is designed to compare the stored measurement values of the field device requiring verification in the course of the analysis to at least one specified limit value, and wherein the analysis program is designed to generate the alarm message in the case that at least one of the measurement values requiring verification exceeds or falls below the specified limit value.

16. The system of claim 12, wherein the decentralized database is designed to store and run smart contracts as program code by means of the subscriber nodes.

17. The system of claim 12, wherein the decentralized database is a private database.

18. The system of claim 12, wherein the communication network is based on an Ethernet protocol.

19. The system of claim 12, wherein the field device is designed as a light node of the decentralized database to provide the data transmitted via the communication network with a time stamp.

20. The system of claim 19, additionally comprising a further light node of the decentralized database in the form of an automation component, especially, a control unit, or a further field device, wherein the further light node has a clock and is designed to generate time stamps and transmit them to the decentralized database, wherein the decentralized database is designed to match the time stamps contained in the data of the field device to the time stamps of the further light node.

21. A method for managing data of a field device in a secure manner against manipulation by means of a decentralized database according to the distributed ledger technology, wherein the decentralized database comprises a plurality of subscriber nodes consisting of validation-capable and/or read-authorized subscriber nodes, wherein an automation field device is provided, which has an electronic unit and a communication interface, comprising: establishing a communication connection between the field device and the decentralized database by means of the communication interface via a wired or wireless communication network; adding the field device to the decentralized database as a light node by running a distributed ledger software stack by means of the electronic unit; generating data by means of the field device, comprising measurement values and/or calibration certificates requiring verification; transmitting the data via the communication network to the decentralized database via the communication network, wherein the data are encrypted; validating the decentralized database by means of the validation-capable subscriber nodes; writing the data to the decentralized database if at least a specified proportion of the validation-capable subscriber nodes successfully validates the data.

22. The method of claim 21, further comprising: decrypting and reading the data by means of read-authorized subscriber nodes.

Description

[0044] The invention is explained in greater detail with reference to the following figures. The figures show:

[0045] FIG. 1: an illustration of a database designed according to the distributed ledger technology; and

[0046] FIG. 2: an exemplary embodiment of the system according to the invention.

[0047] FIG. 1 shows an illustration of a database DB, which is designed according to a distributed ledger technology. In the present case, the database DB is based on the blockchain technology. The blockchain technology became known as a backbone of the Internet currency “Bitcoin.” A blockchain, i.e., a chain of associated data blocks BL1, BL2, BL3, allows high data integrity. The mode of operation of a database DB that is used for the invention is briefly explained below.

[0048] As a rule, said data block BL1, BL2, BL3 consists of at least two components: On the one hand, this is a data field DF. Data in the form of transactions TA are saved in this data field DF. A transmission of the data from a first subscriber node TK1, TK2, . . . , TK6 to a second subscriber node TK1, TK2, . . . , TK6 in a communication network, for example the Internet, is referred to as a transaction TA. A transaction TA contains a transmitted value, for example data of the field device FG, and the transmitter and the recipient of the transaction TA. All devices that form the database or are connected thereto and allow the distributed ledger functionality are referred to as subscriber nodes TK1, TK2, . . . , TK6.

[0049] A data field DF of a data block BL1, BL2, BL3 contains at least one transaction TA, more frequently several transactions TA.

[0050] On the other hand, a data block BL1, BL2, BL3 contains a checksum #1, #2, #3. Such a checksum #1 #2 #3 is a hash value and is created by sometimes complex calculations. For this purpose, all transactions TA of the data field of a block BL1, BL2, BL3 are calculated to form an intermediate value. To accomplish this, the Merkle root of the total number of transactions TA is calculated. The exact functional principle will not be discussed at this point. For this purpose, reference is made, for example, to https://en.wikipedia.org/wiki/Merkle_tree.

[0051] This calculated intermediate value is then used with the checksum #1, #2, #3 of the previous data block BL1, BL2, BL3 to calculate the checksum #1, #2, #3 of the current data block BL1, BL2, BL3. For example, the data block BL2 shown in FIG. 1 contains a checksum #2. This checksum #2 has thus been calculated from the transactions TA stored in the data field DF of the data block B2 and the checksum #1 of the preceding data block BL1. Analogously, the data block BL3 shown in FIG. 1 contains a checksum #3. This checksum #3 has thus been calculated from the transactions TA stored in the data field DF of the data block B3 and the checksum #2 of the preceding data block BL2.

[0052] The integrity of the data, thus the protection of the data against subsequent manipulations, is thus protected by the storage of the checksum #1, #2, #3 of the preceding data block BL1, BL2 in the respectively subsequent data block BL2, BL3. A blockchain thus consists of a series of data blocks BL1, BL2, BL3, in each of which one or more transactions TA are combined and provided with the checksum #1, #2, #3. A change of data generates a changed intermediate value, as a result of which the checksum #1, #2, #3 of the respective data block BL1, BL2, BL3 is also changed. The subsequent data block BL1, BL2, BL3 thus no longer matches the preceding data block BL1, BL2, BL3. Data of a data block BL1, BL2, BL3 that has been successfully validated once are therefore no longer changeable for an attacker.

[0053] New data blocks BL1, BL2, BL3 are created at regular intervals. All transactions TA that were created after the time at which the last data block BL1, BL2, BL3 was created are stored in the data field of the new data block BL1, BL2, BL3.

[0054] The complexity of block creation can be increased in that the created checksum #1, #2, #3 must have a predefined format. For example, it is established that the checksum must be 24 digits long, wherein the first four digits must have the numerical value 0. For this purpose, in addition to the intermediate value of the transactions TA and the checksum of the previous data block, a number sequence to be determined, referred to as “nonce,” with a defined length is used for calculating the checksum #1, #2, #3 of the current data block BL1, BL2, BL3. The calculation of the new checksum #1, #2, #3 accordingly takes longer, since only a few nonces are present, which result in the calculation of a checksum #1, #2, #3 with the specified criteria. The finding of such a suitable nonce causes the described additional time expenditure.

[0055] After the checksum #1, #2, #3 of a new data block BL1, BL2, BL3 has been created, the data block is transmitted to all subscriber nodes TK1, TK2, . . . , TK6. The validation-capable subscriber nodes TK1, TK2, TK3, TK4 now review the checksum #1, #2, #3 of the new data block BL1, BL2, BL3. Only after successful validation is the data block BL1, BL2, BL3 stored in all subscriber nodes TK. Successful validation by more than half of all validation-capable subscriber nodes TK1, TK2, TK3, TK4 is especially required for this purpose. For introducing/creating a foreign, malicious data block BL1, BL2, BL3, an attacker would therefore have to manipulate or control a large number of validation-capable subscriber nodes TK1, TK2, TK3, TK4, in order to successfully validate the introduced data block BL1, BL2, BL3. With an increasing number of validation-capable subscriber nodes TK1, TK2, TK3, TK4, this must be considered to be basically impossible.

[0056] Much less effort is required to validate a data block BL1, BL2, BL3 than to create the data block BL1, BL2, BL3. The checksum #1, #2, #3 is back-calculated, the intermediate value of the transactions TA or the checksum #1, #2, #3 of the previous data block BL1, BL2, BL3 is recovered and compared to the actual intermediate value or to the actual checksum #1, #2, #3 of the previous data block BL1, BL2, BL3. If these values match, the data block BL1, BL2, BL3 is successfully validated.

[0057] The following describes how, with the aid of such a database DB, data of a field device of process automation can be stored in a secure manner against manipulation and can be read for verification purposes:

[0058] FIG. 2 schematically illustrates the system according to the invention. The database DB, which is constructed as described above, consists of the core of four subscriber nodes TK1, TK2, TK3, TK4, which are designed as full nodes. These each store an image AB of the content of the database DB, i.e., the chain of the data blocks DB1, DB2, DB3. Two further, read-capable subscriber nodes TK5, TK6 are connected to the database DB. Furthermore, an automation field device FG is connected, especially, in an Ethernet-based manner, to the database DB by means of a communication interface KS via a communication network KN. By running a distributed ledger software stack, the field device FG a subscriber node and operates as a light node in the database DB, thus can write data to the database DB. However, it cannot verify any transactions. It also does not contain any image AB of the content of the database DB.

[0059] The field device FG detects measurement values that require verification and must be reviewed by an authority at irregular intervals. For this reason, the field device loads these measurement values and associated calibration certificates as data DATA into the database DB. Before transmitting, the database encrypts these data DATA with a private key. Subsequently, the transmitted data DATA are validated as transaction TA by the validation-capable subscriber nodes TK1, TK2, TK3, TK4 and stored in a data field DF of a data block of the database.

[0060] For review, the authority can access the database DB and read the data DATA by means of a computer, which functions as a read-capable subscriber node TK5. For this purpose, the subscriber node TK5 has received a public key in advance, by means of which key the decryption is made possible.

[0061] In the same way, it is possible for the plant operator to access the database DB and to read the data DATA by means of a computer, which functions as a read-capable subscriber node TK6.

[0062] A dashboard BO, which visualizes the data, is displayed to both subscriber nodes TK5, TK6. In the present case, the dashboard DO consists of two columns. The first column shows the names of the subscriber node TK1, . . . , TK6 whose data are stored. The second column shows the data assigned to the subscriber nodes TK1, . . . , TK6 shown in the first column, i.e., for example, the measurement values of the field device FG and possibly assigned calibration certificates.

[0063] As a further feature, so-called smart contracts can be stored in the database DB. Smart contracts are computer protocols that map or review contracts or technically support the negotiation or execution of a contract. They can be stored in the database and run as program code by means of the subscriber nodes TK1, . . . , TK6. The running takes place especially when reading the data DATA on the read-capable subscriber nodes TK5, TK6. For example, the running of such a smart contract enables the reviewing of the calibration certificate, for example whether it was still valid at all for a specific measurement value of the field device. Furthermore, a smart contract can be used to collect penalty payments if a measurement value determined by the field device FG shows unauthorized deviations or a calibration certificate has elapsed.

[0064] Analogously to the smart contracts, analysis programs can be stored in the database DB, which programs can be run by means of the subscriber nodes TK5, TK6 when reading the data. Such an analysis program serves, for example, for the purpose of comparing the stored measurement values of the field device FG requiring verification in the course of the analysis to at least one specified limit value and to generate an alarm message in the case that at least one of the measurement values requiring verification exceeds or falls below the specified limit value.

LIST OF REFERENCE SIGNS

[0065] BL1, BL2, BL3 Data block [0066] BO Dashboard [0067] DB Decentralized database [0068] DATA Data [0069] EL Electronic unit [0070] FG Field device [0071] KN Communication network [0072] KS Communication interface [0073] TA Transaction [0074] TE Transaction creation unit [0075] TK1, . . . , TK6 Subscriber nodes [0076] #1, #2, #3 Hash values of the data blocks