阅读说明：本技术 使用安全的分布式分类账的工业数据验证 (Industrial data validation using secure distributed ledgers ) 是由 本杰明·爱德华·贝克曼 阿尼尔库马尔·瓦达利 拉利特·凯沙夫·梅斯塔 丹尼尔·弗朗西斯·霍尔茨 于 2019-02-25 设计创作，主要内容包括：一种验证平台可包括数据连接件,以接收来自工业资产传感器的包括工业资产数据的子集的工业资产数据流。验证平台可将工业资产数据的子集存储到数据存储器中,该工业资产数据的子集被标记为无效,并将与和元数据组合的工业资产数据的子集的压缩表示相关联的散列值记录在(例如,与区块链技术相关联的)安全的分布式分类账中。然后,该验证平台可从安全的分布式分类账中接收交易标识符,并且在使用该交易标识符来验证所记录的散列值匹配与元数据组合的工业资产数据的子集的压缩表示的独立创建的版本的散列值之后,将数据存储器中的工业资产数据的子集标记为有效。(An authentication platform can include a data connection to receive an industrial asset data stream including a subset of industrial asset data from an industrial asset sensor. The validation platform can store a subset of the industrial asset data into the data store, the subset of the industrial asset data marked as invalid, and record a hash value associated with the compressed representation of the subset of the industrial asset data combined with the metadata in a secure distributed ledger (e.g., associated with blockchain techniques). The validation platform can then receive a transaction identifier from the secure distributed ledger and mark the subset of industrial asset data in the data store as valid after using the transaction identifier to validate that the recorded hash value matches a hash value of an independently created version of the compressed representation of the subset of industrial asset data combined with the metadata.)

1. A system that facilitates industrial data validation, comprising:

a verification platform comprising:

a data connection to receive an industrial asset data stream comprising a subset of the industrial asset data from the industrial asset sensor, an

At least one verification platform computer processor coupled to the data connection and adapted to:

storing a subset of the industrial asset data in a data store, the subset of the industrial asset data being marked as invalid,

recording a hash value associated with the compressed representation of the subset of industrial asset data combined with metadata in a secure distributed ledger,

receiving a transaction identifier from the secure distributed ledger, an

Marking the subset of the industrial asset data in the data store as valid after verifying that the recorded hash value matches a hash value of an independently created version of the compressed representation of the subset of the industrial asset data combined with metadata using the transaction identifier.

2. The system of claim 1, further comprising:

the data store, wherein the data store is adapted to provide information marked as valid to a consuming platform.

3. The system of claim 1, wherein the compressed representation of the subset of industrial data combined with metadata comprises a dictionary tree.

4. The system of claim 3, wherein the compressed representation of the subset of industrial data combined with metadata comprises a patricia-mercker dictionary tree.

5. The system of claim 1, wherein the metadata comprises at least one of: (i) a pseudo identifier, (ii) a timestamp, (iii) a unique client identifier, and (iv) data shape information.

6. The system of claim 1, wherein the verification platform is associated with at least one of: (i) a single network cloud hosting topology, (ii) multiple network cloud hosting topologies, and (iii) participant hosted intranet environments.

7. The system of claim 1, wherein the industrial asset sensor is associated with at least one of: (i) an engine, (ii) an airplane, (iii) a locomotive, (iv) a generator, and (v) a wind turbine.

8. The system of claim 1, wherein the secure distributed ledger comprises a blockchain technique.

9. A method associated with industrial data validation, comprising:

receiving, at a computer processor of a validation platform, an industrial asset data stream comprising a subset of the industrial asset data from an industrial asset sensor;

storing, by the validation platform, a subset of the industrial asset data into a data store, the subset of the industrial asset data being marked as invalid;

recording, by the validation platform, a hash value associated with the compressed representation of the subset of the industrial asset data combined with metadata in a secure distributed ledger;

receiving, at the validation platform, a transaction identifier from the secure distributed ledger; and

marking, at the validation platform, the subset of the industrial asset data in the data store as valid after validating that the recorded hash value matches a hash value associated with an independently created version of the compressed representation of the subset of the industrial asset data combined with metadata using the transaction identifier.

10. The method of claim 9, wherein the compressed representation of the subset of industrial data combined with metadata comprises a patricia-mercker dictionary tree.

11. The method of claim 9, wherein the metadata comprises at least one of: (i) a pseudo identifier, (ii) a timestamp, (iii) a unique client identifier, and (iv) data shape information.

12. The method of claim 1, wherein the secure distributed ledger comprises a blockchain technique.

13. A system that facilitates industrial data validation, comprising:

a verification client, comprising:

a data connection to receive an industrial asset data stream comprising a subset of the industrial asset data from the industrial asset sensor, an

A verification client computer processor coupled to the data connector and adapted to:

creating a patricia-mercker dictionary tree from the subset of industrial asset data and the metadata,

determining a trie hash value associated with the patricia-mercker trie,

receiving a pseudo identifier from a verification engine, an

The raw patricia-mercker dictionary tree data is transmitted to the verification server along with the metadata,

the verification engine, comprising:

a verification engine computer processor adapted to:

receiving the hash value from the authentication client,

transmitting a pseudo-identifier to the authentication client,

the received trie hash values are recorded in a secure distributed ledger,

receiving a transaction identifier from the secure distributed ledger, an

Transmitting the pseudo identifier and transaction identifier to the authentication server, an

The authentication server includes:

an authentication server computer processor adapted to:

receiving the subset of industrial asset data and metadata from the validation client,

receiving the pseudo identifier and the transaction identifier from the validation engine,

storing a subset of the industrial asset data in a data store, the subset of the industrial asset data being marked as invalid,

separately creating a patricia-mercker dictionary tree from the received subset of industrial asset data and metadata,

retrieving the recorded hash value from the secure distributed ledger, an

After verifying that the recorded hash value matches a hash value associated with an independently created patricia-mercker dictionary tree, marking a subset of the industrial asset data in the data store as valid.

14. The system of claim 13, wherein the metadata comprises at least one of: (i) the pseudo identifier, (ii) a timestamp, (iii) a unique client identifier, and (iv) data shape information.

15. The system of claim 13, wherein the verification platform is associated with at least one of: (i) a single network cloud hosting topology, (ii) multiple network cloud hosting topologies, and (iii) participant hosted intranet environments.

16. The system of claim 13, wherein the industrial asset sensor is associated with at least one of: (i) an engine, (ii) an airplane, (iii) a locomotive, (iv) a generator, and (v) a wind turbine.

17. The system of claim 13, wherein the secure distributed ledger comprises a blockchain technique.

18. The system of claim 13, further comprising:

the data store, wherein the data store is adapted to provide information marked as valid to a consuming platform.

19. The system of claim 18, further comprising:

the consumption platform is adapted to utilize information marked as valid in the data store.

20. The system of claim 19, further comprising:

an industrial asset item comprising the industrial asset sensor to generate an industrial asset data stream comprising a subset of industrial asset data.

Technical Field

Some embodiments disclosed herein relate to industrial assets and, more particularly, to systems and methods for validating industrial data using a secure distributed ledger.

Background

Recent technological advances have resulted in increased connectivity relative to industrial space. With the advent of smart devices and industrial internet and other technologies, the ability to improve the operation of systems (e.g., manufacturing plants) and industrial assets very quickly has improved substantially based on the large amount of data, most of which is data collected from interconnected sensors. For example, the performance of gas turbines, jet engines, and the like may be monitored to improve performance and avoid failure. However, these advantages may also have adverse consequences. For example, unauthorized parties may exploit many vulnerabilities in industrial systems to destroy industrial assets. Sensor data from oil pipelines, hydraulic systems, gas turbines, and other industrial equipment is considered, which may be altered to give erroneous readings or corrupted data. The result of such changes may cause the automatic controller and human operator to take incorrect corrective action. These behaviors can cause a huge confusion of society and increase the operating costs of factories and manufacturing plants.

To avoid such consequences, the centralized architecture may utilize a database that stores hash values that may be used to verify industrial data. However, since all of the content is stored in a single master copy or database, a single compromised element in the architecture may risk the entire system and allow manipulation or destruction of the data. Accordingly, it is desirable to provide systems and methods that effectively and accurately facilitate industrial data validation.

Disclosure of Invention

According to some embodiments, a system may include a validation platform having a data connection to receive an industrial asset data stream including a subset of industrial asset data from an industrial asset sensor. The validation platform can store a subset of the industrial asset data into the data store, the subset of the industrial asset data marked as invalid, and record a hash value associated with the compressed representation of the subset of the industrial asset data combined with the metadata in a secure distributed ledger (e.g., associated with blockchain techniques). The validation platform can then receive a transaction identifier from the secure distributed ledger and mark the subset of industrial asset data in the data store as valid after using the transaction identifier to validate that the recorded hash value matches a hash value of an independently created version of the compressed representation of the subset of industrial asset data combined with the metadata.

Some embodiments include: means for receiving an industrial asset data stream comprising a subset of the industrial asset data from an industrial asset sensor; means for storing a subset of the industrial asset data into a data store, the subset of the industrial asset data being marked as invalid; means for recording a hash value associated with the compressed representation of the subset of industrial asset data combined with the metadata in a secure distributed ledger; means for receiving a transaction identifier from a secure distributed ledger; and means for marking the subset of industrial asset data in the data store as valid after verifying, at the verification platform, that the recorded hash value matches a hash value associated with an independently created version of the compressed representation of the subset of industrial asset data of the metadata combination using the transaction identifier.

Technical effects of some embodiments of the present invention may include improved and computerized ways to efficiently and accurately facilitate industrial data validation. A more complete understanding of the nature of the present invention may be derived by referring to the following detailed description and accompanying drawings that are apparent from and will be described below.

Drawings

FIG. 1 is a high-level block diagram of a system according to some embodiments.

FIG. 2 is a method of validating industrial data, according to some embodiments.

FIG. 3 is an example of a trie according to some embodiments.

FIG. 4 is a more detailed process for industrial data validation, according to some embodiments.

FIG. 5 is a more detailed method for industrial data validation, according to some embodiments.

FIG. 6 illustrates a merkel (Merkle) tree in accordance with some embodiments.

Figure 7 is a system for implementing digital transactions using blockchain verification, in accordance with some embodiments.

FIG. 8 is a system for implementing digital transactions using multiple digital transaction engines, according to some embodiments.

FIG. 9 is a high-level block diagram of an authentication client system according to some embodiments.

FIG. 10 is a verify client method according to some embodiments.

FIG. 11 is a high-level block diagram of a verification engine system according to some embodiments.

FIG. 12 is a verification engine method according to some embodiments.

FIG. 13 is a high-level block diagram of an authentication server system according to some embodiments.

FIG. 14 is an authentication server method according to some embodiments.

FIG. 15 illustrates a platform according to some embodiments.

FIG. 16 is a portion of a table data store according to some embodiments.

FIG. 17 illustrates a computer display according to some embodiments.

FIG. 18 is a distributed ledger referencing architecture, according to some embodiments.

FIG. 19 illustrates which components in a system may have knowledge of a transaction identifier, according to some embodiments.

FIG. 20 illustrates which components in a system may have knowledge of the dictionary tree data, in accordance with some embodiments.

FIG. 21 illustrates a tablet computer provided with a display according to some embodiments.

Detailed Description

In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the embodiments. However, it will be understood by those of ordinary skill in the art that the embodiments may be practiced without these specific details. In other instances, well-known methods, procedures, components and circuits have not been described in detail so as not to obscure the embodiments.

One or more specific embodiments of the present invention will be described below. In an effort to provide a concise description of these embodiments, all features of an actual implementation may not be described in the specification. It should be appreciated that in the development of any such actual implementation, as in any engineering or design project, numerous implementation-specific decisions must be made to achieve the developers' specific goals, such as compliance with system-related and business-related constraints, which may vary from one implementation to another. Moreover, it should be appreciated that such a development effort might be complex and time consuming, but would nevertheless be a routine undertaking of design, fabrication, and manufacture for those of ordinary skill having the benefit of this disclosure.

It may be generally desirable to efficiently and accurately facilitate industrial data validation. Fig. 1 is a high-level block diagram of a system 100 according to some embodiments. Specifically, the system 100 includes a verification platform 150 having a communication port 140, the communication port 140 for receiving the industrial asset data stream 120 (including values T0, T1, T2, etc.) from sensors and other components of the industrial asset 110. Verification platform 150 may receive subset 130 of data stream 120 and store information marked as "invalid" into data store 110. The verification platform 150 may then utilize the secure distributed ledger 190 to verify this information and then mark the stored data as "valid" so that the data can be used securely by the consumption platform 170.

According to some embodiments, the data store 160 stores electronic records defining the received industrial data stream 120. According to some embodiments, the verification platform 150 and/or other elements of the system may then record information about various transactions using the secure distributed ledger 190 (e.g., through a blockchain verification process). For example, the verification platform 150 may record a date and time, a hash value, etc. via the secure distributed ledger 190 according to any of the embodiments described herein. According to some embodiments, a distributed ledger may be associated with a super ledger

The blockchain verification system is associated. It should be noted that the verification platform 150 may be completely decentralized and/or may be associated with a third party, such as a provider that fulfills services for the enterprise.

The verification platform 150 may be associated with, for example, a personal computer ("PC"), a laptop, a tablet, a smartphone, an enterprise server, a server farm, and/or a database or similar storage device. According to some embodiments, the "automated" verification platform 150 may automatically verify industrial data. As used herein, the term "automated" may refer to actions that may be performed, for example, with little (or no) human intervention.

As used herein, devices, including those associated with the authentication platform 150 and any other devices described herein, may exchange information via any communication network, which may be one or more of a local area network ("LAN"), a metropolitan area network ("MAN"), a wide area network ("WAN"), a proprietary network, a public switched telephone network ("PSTN"), a wireless application protocol ("WAP") network, a bluetooth network, a wireless LAN network, and/or an internet protocol ("IP") network, such as the internet, an intranet, or an extranet. It should be noted that any of the devices described herein may communicate via one or more such communication networks.

Verification platform 150 may store information in and/or retrieve information from a data store. The data store may, for example, store electronic records representing industrial asset sensor data, operational data, and the like. The data store may be stored locally or remotely from the verification platform 150. Although shown in FIG. 1 as a single verification platform 150, any number of such devices may be included. Furthermore, the various devices described herein may be combined in accordance with embodiments of the present invention. In some embodiments, verification platform 150, data store 160, and/or other apparatus may cooperate and/or may comprise a single device. For example, the verification platform 150 may be associated with a single network cloud hosting topology, multiple network cloud hosting topologies, participant hosted intranet environments, and so forth.

In this manner, the system 100 can efficiently and accurately facilitate industrial data validation. For example, FIG. 2 is a method 200 of encoding a signature identifier into an item, according to some embodiments. The flow charts described herein do not imply a fixed order to the steps and embodiments of the present invention may be practiced in any order that is practicable. It is noted that any of the methods described herein may be performed by hardware, software, or any combination of these means. For example, a computer-readable storage medium may store instructions thereon that when executed by a machine result in performance according to any of the embodiments described herein.

At 210, the computer processor of the validation platform can receive an industrial asset data stream including a subset of the industrial asset data (e.g., a "package" of data) from the industrial asset sensor. It should be noted that the verification platform may be associated with a single network cloud hosting topology, multiple network cloud hosting topologies, participant hosted intranet environments, and the like. Further, industrial asset items may be associated with engines, airplanes, locomotives, generators, wind turbines, etc., by way of example only. At 220, the validation platform can store the subset of the industrial asset data marked as invalid in a data store.

At 230, the validation platform can record hash values associated with the compressed representation of the subset of the industrial asset data combined with the metadata in a secure distributed ledger. According to some embodiments, the compressed representation of the subset of industrial data combined with the "metadata" is a dictionary tree (trie), although other types of compressed representations of data may be used. It should be noted that the metadata may include, for example, a pseudo-identifier, a timestamp, a unique client identifier, data shape information (e.g., depth and/or width of the data), and so forth. FIG. 3 is an example of the types of tries 300 that may be used as compressed representations of industrial data, according to some embodiments. As used herein, the term "trie" may refer to a radix tree that may be used to store an ordered search tree data structure of a dynamic set or associative array (and a key may include, for example, a string). It should be noted that the next generation of a node 310 in the trie 300 has a common prefix of the string associated with that node 310, and the root may be associated with an empty string. The example of fig. 3 stores eight strings: "pat", "patent", "protected", "patrick", "track", "tracks", and "track". Starting from root node 310, the bold arrows in fig. 3 indicate starting from root node 310. A search is shown that combines "pat", "ent" and "ed" to form the string "protected". Note that each node 310 in the trie 300 has at most two child nodes (referred to as a "binary" trie or a trie with radix "2").

Referring again to FIG. 2, at 240, the validation platform can receive a transaction identifier from the secure distributed ledger. At 250, the verification platform can mark the subset of industrial asset data in the data store as valid after verifying, using the transaction identifier, that the recorded hash value matches a hash value associated with an independently created version of the compressed representation of the subset of industrial asset data combined with the metadata. The consuming platform may then make use of the information marked as valid in the data store.

In this manner, the data verification platform can protect and authenticate sensor data output from the industrial system and further ensure that corrupted data does not flow to other critical systems. A more detailed description of the process of validating industrial data is provided in connection with the system of fig. 4, utilizing the security aspects of distributed ledgers (such as blockchain techniques) and compressed data structures (such as dictionary trees). The system 400 includes a validation platform 450, the validation platform 450 including a validation client 452 that receives an industrial asset data stream, a validation engine 454, and a validation server 456 that stores data in a data store 460. It should be noted that system 400 is applicable to many applications, including engine configuration management and configuration management of other asset types.

The verification client 452 initially establishes a connection with the industrial asset and waits for data to be sent. Once the data packet is received by the verification client 452, the data is stored using a data structure (e.g., a dictionary tree). As described with respect to fig. 6, according to some embodiments, a "Patricia-Merkle" dictionary tree may store data using paired key-values within the dictionary tree. For example, the key may be based on a timestamp when the first item of the data packet is read along the data shape. The structure is characterized by a special hash and may be linked to a root node of the data structure that identifies each trie. Thus, the hash can be used as a fingerprint for the entire structure, and when any data is modified in the trie, the hash will automatically change. After storing the data, the verification client 452 sends the hash to the verification engine 454 at (a) and listens for a "pseudo-identifier" at (B). The pseudo-identifier may include a unique identifier that will link all data built into the particular dictionary tree. The client then sends the data packet and associated metadata to the authentication server at (E).

The verification engine 454 may initially connect to the verification client 452 and listen for packets containing hashes of the trie created by the verification client 452. Upon receiving the hash, the verification engine 454 sends back the pseudo identifier. The validation engine 454 may then store or record the hash into the secure distributed ledger 490 at (C1) and receive a transaction identifier that may be used to monitor the hash stored in the ledger 490 (e.g., blockchain) at (C2). Next, the verification engine 454 closes the connection with the verification client 452 and opens the connection with the verification server 456. Once the connection is opened, the validation engine 454 may send the transaction identifier and pseudo identifier to the validation server 456 at (D), and the validation server 456 may utilize both identifiers accordingly.

Authentication server 456 may continuously listen to authentication client 452 and authentication engine 454 to wait for information. First, the validation server 456 may receive the transaction identifier and pseudo identifier from the validation engine 454 at (D) and store them for future use. Authentication server 456 may also receive the data packet sent from authentication client 452 at (E) and store it in data store 460 at (F). At this point, all data is invalid and marked as such in the data store (as indicated by the dashed arrow in FIG. 4). The validation server 456 may then build its own trie from the received data, which will also have hash values. To check if the data is valid, the validation server 456 compares the current hash with the hash stored in the ledger 490 at (G). Using the stored transaction identifier, the validation server 456 can retrieve the hash from the distributed ledger 490 and compare the hash from the ledger 490 to the locally created hash. If the two values match, the validation server 456 validates, at (H), the data associated with the hash using the stored pseudo-identifier by marking the data in the data store 460 as valid (if not, the data in the data store 460 remains invalid). It should be noted that any consuming platform 470 may read the verified data from data store 460 at (I).

In this manner, the system 400 may help ensure that the sensor data received by the controller and operator is indeed anchored in time and has been verified. According to some embodiments, this is accomplished by protecting data using a secure infrastructure, such as block chains and cryptographically protected compressed data structures (e.g., patricia-mercker dictionary trees). Further, embodiments may let the user know exactly when data is changed, and also help the user respond as soon as possible.

Fig. 5 is a more detailed method 500 for industrial data validation, according to some embodiments.

At 510, a dictionary tree (such as the patricia-mercker dictionary tree described with respect to fig. 6) is created to store the received data packets and the dictionary tree hashes from the verification client are sent to the verification engine. At 520, the pseudo identifier is sent from the authentication engine to the authentication client. At 530, the verification engine records the trie hash in the blockchain and receives the transaction identifier from the blockchain. At 540, the validation engine sends the pseudo identifier and the transaction identifier to the validation server. At 550, the verification client sends the data packet and associated metadata to the verification server. At 560, the validation server stores the data packet marked invalid in a data store. At 570, the verification server retrieves the trie hash of the record from the blockchain and independently verifies that the trie hash matches the locally created hash value. Assuming the two hash values match, the authentication server marks the data in the data store as valid at 580. At 590, the consuming platform may access valid data from the data store, and the process continues at 510.

According to some embodiments, the lossless protection process may be associated with a "Merkle tree". Fig. 6 shows a merkel tree 600 that can be used in a digital signature system, where the security of the system depends on the security of conventional cryptographic functions. The tree 600 may provide for generating a secret number X_iA digital signature of the type (2), wherein X_i＝x_i1，x_i2，x_i3…x_inCalculating Y_i＝F(X_i) And mixing X_iIs sent to the receiver as a digital signature. According to some embodiments, the authentication tree 600 uses a tree including Y_iThe authentication tree function of the one-way function of (1). The root of the authentication tree and the authentication tree function may be authenticated at the receiver. Y of authentication tree_iAnd corresponding authentication path values may be transmitted from the sender to the receiver and authenticated by calculatingBetween Y of tree_iAnd the rest of the authentication tree, Y can be paired at the receiver_iAnd (6) performing authentication. In the example of fig. 6, n is equal to 8.

To set Y as the data item₁，Y₂，...，Y_nThe vector implements a 'tree authentication' method, providing a random selection of Y_iA method of performing authentication. To authenticate Y_iThe function H (I, j, Y) is defined as follows:

H(i,i,Y)＝F(Y_i)

H(i,j,Y)＝F(H(i,i+j-1/2,Y),H(i+j+1)/2,j,Y))

wherein F (Y)_i) Is a one-way function. H (I, j, Y) is Y_i，Y_i+1...Y_jAnd H (1, n, Y) can be used to authenticate Y₁To Y_n. H (1, n, Y) is all Y_iA one-way function of (H (1, n, Y) may contain 100 bits of data, as an example only). In this manner, the receiver can selectively authenticate any "leaf" Y of the binary tree 600 defined by the function H (i, n, Y)_i。

For example, the recursive call sequence required to compute the root H (1,8, Y) of the binary tree 600 is shown in fig. 6. Once the root H (1,8, Y) is computed, it is authenticated to the receiver along with the function H (). To verify any Y_i(such as Y)₅) The transmitter and receiver may perform the following operations:

(a) h (1,8, Y) is known and certified.

(b) H (1,8, Y) ═ F (H (1,4, Y), H (5,8, Y)). H (1,4, Y) and H (5,8, Y) are transmitted, and the receiver is caused to calculate that H (1,8, Y) is F (H (1,4, Y), H (5,8, Y)), and confirm that H (5,8, Y) is correct.

(c) The receiver is authenticated H (5,8, Y). H (5,6, Y) and H (7,8, Y) are transmitted, and the receiver is caused to calculate H (5,8, Y) as F (H (5,6, Y), H (7,8, Y), and confirm that H (5,6, Y) is correct.

(d) The receiver is authenticated H (5,6, Y). H (5,5, Y) and H (6,6, Y) are transmitted, and the receiver is caused to calculate that H (5,6, Y) ═ F (H (5,5, Y), H (6,6, Y)), and confirm that H (5,5, Y) is correct.

(e) The receiver is authenticated H (5,5, Y). Sending Y₅And causing the receiver to calculate H (5,5, Y))＝F(Y₅) And confirm that it is correct.

(f) The receiver is authenticated Y5.

Some embodiments described herein utilize a particular type of merkel tree known as the utility algorithm for retrieving alphanumeric encoded information ("patticia") or the PATRICIA-merkel dictionary tree. The patricia-mercker dictionary tree may provide a data structure that may be used to store cryptographic authentications for all (key, value) bindings. They may be completely deterministic, meaning that patricia dictionary trees with the same (key, value) binding guarantee that up to the last byte are all identical and therefore have the same root hash. In addition, the patricia-mercker dictionary tree may provide O (log (n)) efficiency for insertions, lookups, and deletions. It should be noted that, as described herein, using the patricia-mercker dictionary tree as a method of compressing, storing, and uniquely identifying data (e.g., instead of a hash table) means that there will not be any key conflicts that may corrupt or overwrite existing data. Furthermore, the compression characteristics and relatively low levels of temporal and spatial complexity of the patricia-mercker dictionary tree may allow for the storage of large amounts of data within the dictionary tree. In addition, the system can quickly determine whether the data has been corrupted. Thus, the ability to utilize the root node hashes of the trie as data fingerprints stored in the trie can facilitate checksum verification in a relatively fast manner.

FIG. 7 is a system 700 for implementing industrial data validation using blockchain verification, in accordance with some embodiments. Cloud-based integrity monitor 710 may provide transaction integrity data via a web browser and exchange information with blockchain 720 and validation engine 750 via a representational state transfer ("REST") web service. REST web services may, for example, provide interoperability between computer systems on the internet (e.g., by allowing a requesting system to access and manipulate textual representations of network resources using a unified, predefined set of stateless operations). According to some embodiments, portions of the validation engine 750 may be associated with a MySQL database. In this manner, verification engine 750 and blockchain 720 may be used to provide transaction-level verification for client 740. Although fig. 7 illustrates a system 700 with a single blockchain 720 and a verification engine 750, it should be noted that embodiments may employ other topologies. For example, fig. 8 is a system 800 that applies a cloud-based verification monitor 810 to support industrial data verification using multiple verification engines, according to some embodiments. In particular, additional blockchains 822 and verification engines 852 can provide protection for additional clients 842. As shown in fig. 8, each verification engine 850, 852 may be associated with multiple blockchains 820, 822 that provide additional protection for the system 800 (e.g., by storing information on multiple nodes that are geographically dispersed, making attacks impractical). That is, each validator (e.g., validation engine) can submit a brief overview to a separate data store and, once logged, cannot change information without detection to provide a tamper-resistant logging system ("SoR").

Although some embodiments have been described using a specific blockchain technique, it is noted that other approaches may be incorporated. For example, a chain point (Chainpoint) platform for a blockchain may be utilized to allow for the creation of a time stamp attestation of data and to verify the presence and integrity of data stored in the blockchain. That is, rather than manually checking whether the hashes match at the authentication server, the authentication platform and chain point attestation may be implemented as an authentication tool.

FIG. 9 is a high-level block diagram of an authentication client system 900 according to some embodiments. The system 900 includes a verification client 952 having a data connection to receive an industrial asset data stream including a subset of the industrial asset data from the industrial asset sensor. Verification client 952 creates a dictionary tree from the received data and sends the data and associated metadata to verification server 956. Verification client 952 also sends the trie hash to verification engine 954 and receives the returned pseudo identifier. Fig. 10 is a verify client method 1000 according to some embodiments. At 1010, the verification client creates a patricia-mercker dictionary tree from the subset of industrial asset data and the metadata. At 1020, the authentication client determines a hash value associated with the patricia-mercker dictionary tree. At 1030, the authentication client receives the pseudo identifier from the authentication engine. At 1040, the verification client transmits the original patricia-mercker dictionary tree data to the verification server along with the metadata.

FIG. 11 is a high-level block diagram of a verification engine system 1100 according to some embodiments. The system 1100 includes a verification engine 1154 to receive and record the trie hash from the verification client 1152 in a secure distributed ledger 1190 (receiving the returned transaction identifier). The authentication engine 1154 also locally generates a pseudo identifier that is provided to the authentication client. The validation engine also sends the transaction identifier to the validation server 1156 along with the locally generated pseudo-identifier. FIG. 12 is a verification engine method 1200 according to some embodiments. At 1210, the verification engine receives a hash value from a verification client. At 1220, the authentication engine transmits the locally created pseudo identifier to the authentication client. At 1230, the verification engine records the trie hash in the secure distributed ledger and receives the returned transaction identifier at 1240. At 1250, the verification engine transmits the pseudo identifier and associated transaction identifier to the verification server (which may then use the pair of values to thereafter identify the appropriate data packet).

Fig. 13 is a high-level block diagram of an authentication server system 1300 according to some embodiments. The system includes a verification server 1300 that receives raw dictionary tree data and metadata from a verification client 1352 and uses that data to independently create a patricia-mercker dictionary tree (and associated hash values) locally. That is, the trie is created separately from the trie created by the verification client 1352. The transaction server also receives the pseudo identifier and transaction identifier from the verification engine 1354 and retrieves the trie hash previously recorded by the verification engine 1354 in the secure distributed ledger 1390. The validation server initially writes the data packets marked invalid to data store 1360. If the locally determined hash value matches the hash value received from secure distributed ledger 1390, then validation server 1356 updates data store 1360 by marking the data as valid. FIG. 14 is an authentication server method 1400 according to some embodiments. At 1410, the validation server can receive the subset of industrial asset data and the metadata from the validation client. At 1420, the client may receive the pseudo identifier and the transaction identifier from the verification engine. The validation server can then store a subset of the industrial asset data in a data store at 1430, wherein the subset of the industrial asset data is marked as invalid. At 1440, the verification engine can independently create a patricia-mercker dictionary tree from the received subset of industrial asset data and the metadata. At 1450, the validation server may retrieve the hash value of the record from the secure distributed ledger. Then, at 1460, after verifying that the recorded hash values match hash values associated with the independently created patricia-mercker dictionary tree, the verification server may mark a subset of the industrial asset data in the data store as valid.

Embodiments described herein may include tools to facilitate industrial data validation and may be implemented using any number of different hardware configurations. For example, fig. 15 illustrates a platform 1500 that may be associated with, for example, the systems 150, 400 of fig. 1 and 4 (and other systems described herein), respectively. The platform 1500 includes a processor 1510, such as one or more commercially available central processing units ("CPUs") in the form of a single chip microprocessor, the processor 1510 being coupled to a communication device 1520 configured to communicate via a communication network (not shown in fig. 15). The communication device 1520 can be used to communicate, for example, with one or more remote industrial assets, data stores, ledgers, and the like. It is noted that communications exchanged via communications device 1520 may utilize security features such as those between public internet users and the insurance enterprise's internal network. The security features may be associated with, for example, a web server, a firewall, and/or a PCI infrastructure. Platform 1500 further includes input devices 1540 (e.g., a mouse and/or keyboard for inputting information about distributed ledgers, industrial assets, etc.) and output devices 1550 (e.g., for outputting status reports, generating alarm messages, etc.).

The processor 1510 also communicates with a storage device 1530. Storage 1530 may include any suitable information storage device, including a combination of magnetic storage (e.g., hard disk drives), optical storage, mobile phones, and/or semiconductor storage. The storage 1530 stores the program 1512 and/or network security service tool or application for controlling the processor 1510. The processor 1510 executes instructions of the program 1512 and thus operates according to any of the embodiments described herein. For example, the processor 1510 can receive an industrial asset data stream comprising a subset of the industrial asset data from an industrial asset sensor. The processor 1510 can store a subset of the industrial asset data into the data store 1600 that is marked as invalid and record a hash value associated with the compressed representation of the subset of the industrial asset data combined with the metadata in a secure distributed ledger (e.g., associated with blockchain techniques). The processor 1510 can then receive a transaction identifier from the secure distributed ledger and mark the subset of industrial asset data in the data store 1600 as valid after using the transaction identifier to verify that the recorded hash value matches a hash value of an independently created version of the compressed representation of the subset of industrial asset data combined with the metadata.

The program 1512 can be stored in a compressed, uncompiled, and/or encrypted format. Programs 1512 may also include other program elements used by processor 1510 (e.g., an operating system, a database management system, and/or device drivers) to interface with peripheral devices.

As used herein, information may be "received" or "transmitted" to, for example, the following: (i) from another device to platform 1500; or (ii) to a software application or module within platform 1500 from another software application, module, or any other source.

In some embodiments (such as shown in fig. 15), the storage 1530 also stores raw data 1560 (e.g., information packets received from sensors of an industrial asset), a patricia-mercker dictionary tree 1570, and data storage 1600. An example of a database that may be used in conjunction with platform 1500 will now be described in detail with reference to FIG. 16. It is noted that the databases described herein are merely examples, and additional and/or different information may be stored therein. Further, the various databases may be split or combined according to any of the embodiments described herein. For example, raw data 1560 and patricia-mercker dictionary tree 1507 may be combined and/or linked with each other within program 1512.

Referring to FIG. 16, a table representing data store 1600 that may be stored at platform 1500 is illustrated, in accordance with some embodiments. The table may include, for example, entries identifying data packets that have been received from industrial asset sensors. The table may also define fields 1602, 1604, 1606, 1608 for each entry. According to some embodiments, the fields 1602, 1604, 1606, 1608, 1614 may specify: a transaction identifier 1602, a subset of industrial data 1604, a date and time 1606, and a validity indication 1608. The data store 1600 can be created and updated, for example, based on electronic information received from remote industrial assets, validation clients, validation engines, and/or distributed ledger devices.

The transaction identifier 1602 may, for example, be a unique alphanumeric code that identifies a data packet that has been received from an industrial asset sensor (e.g., as part of a larger data stream). The subset of industrial data 1604 may include actual values (e.g., temperature, speed, power level, etc.) received from the sensors. Date and time 1606 may indicate when the system generated or received the data. The validity indication 1608 may indicate that the data is "invalid" (not yet verified) or "valid" (e.g., a hash of a separately created patricia-mercker dictionary tree matches a hash value recorded in a secure distributed ledger). The data store 1600 may be configured such that information associated with a validity indication of "valid" may be provided to a remote consuming platform.

Although specific hardware and data configurations have been described herein, it is noted that any number of other configurations may be provided in accordance with embodiments of the present invention (e.g., certain information described herein may be combined or stored in an external system). Similarly, the displays shown and described herein are provided as examples only, and other types of displays and display devices may support any embodiment. For example, FIG. 17 illustrates a verification platform display 1700 that may utilize an interactive graphical user interface. Display 1700 may include a graphical overview of a verification system that includes industrial assets 1710, a verification platform 1750 (including verification clients, engines, and servers), and data storage 1760. According to some embodiments, the data storage 1760 may indicate which data packets have been received from the sensors of the industrial asset 1710 and a valid/invalid indication reflecting whether each packet has been verified. Selecting an element on display 1700 (e.g., via a touch screen or computer mouse pointer 1730) may result in more information about the element (and in some cases, allow adjustments to be made with respect to the element). In addition, selecting "alert" icon 1740 may trigger an electronic message indicating something appears to be wrong (e.g., the data packet has stopped being verified), and allow remedial action to be taken.