JP7615844B2 - Verification device, verification method, and verification program - Google Patents

Description

The present invention relates to a verification device, a verification method, and a verification program.

Patent Document 1 describes "an encryption control system, an encryption control method, and a program that enable enhanced security."
[Prior Art Literature]
[Patent Documents]
[Patent Document 1] Japanese Patent No. 6360781

In a first aspect of the present invention, a verification device is provided. The verification device may include a data acquisition unit that acquires target data, which is data in a target processing device to be managed, in a data processing system in which data is propagated or converted via multiple processing devices. The verification device may include a block generation unit that generates, based on the target data, a target block to be registered in a blockchain that records blocks based on data in each of the multiple processing devices. The verification device may include a verification request unit that supplies the target block to multiple verification devices that manage the multiple processing devices, respectively, and requests verification of the target block. The verification device may include a registration unit that registers the target block in the blockchain in response to a verification result from at least one of the multiple verification devices.

The verification device may further include an output unit that outputs an abnormality message when the verification result indicates that the verification of the target block has failed.

The verification device may further include an encryption unit that encrypts the target block for each of the plurality of verification devices. The verification request unit may supply each of the target blocks encrypted for each of the plurality of verification devices to each of the plurality of verification devices.

The registration unit may register the target block in the blockchain in response to a verification result from a main verification device that is to supply the verification result among the multiple verification devices.

The data processing system may be a control system that controls a control target based on control parameters generated via the multiple processing devices. The main verification device may be a verification device that manages a controller that provides a control command to the control target according to the control parameters.

The verification device may further include a calculation unit that calculates a hash value based on an upstream block that has been registered in the blockchain. The block generation unit may generate the target block that includes the hash value.

The data acquisition unit may acquire input data input from an upstream processing device in the target processing device, and output data to be output to a downstream processing device. The block generation unit may generate the target block including the input data and the output data.

In a second aspect of the present invention, a verification method is provided. The verification method may comprise acquiring target data, which is data in a target processing device to be managed, in a data processing system in which data is propagated or transformed via a plurality of processing devices. The verification method may comprise generating, based on the target data, a target block to be registered in a blockchain that records blocks based on data in each of the plurality of processing devices. The verification method may comprise supplying the target block to a plurality of verification devices that respectively manage the plurality of processing devices, and requesting verification of the target block. The verification method may comprise registering the target block in the blockchain in response to a verification result from at least one of the plurality of verification devices.

In a third aspect of the present invention, a verification program is provided. The verification program may be executed by a computer. The verification program may cause the computer to function as a data acquisition unit that acquires target data, which is data in a target processing device to be managed, in a data processing system in which data is propagated or converted via a plurality of processing devices. The verification program may cause the computer to function as a block generation unit that generates, based on the target data, a target block to be registered in a blockchain that records blocks based on data in each of the plurality of processing devices. The verification program may cause the computer to function as a verification request unit that supplies the target block to a plurality of verification devices that each manage the plurality of processing devices, and requests verification of the target block. The verification program may cause the computer to function as a registration unit that registers the target block in the blockchain in response to a verification result from at least one of the plurality of verification devices.

In a fourth aspect of the present invention, a verification device is provided. The verification device may include a block acquisition unit that acquires a target block to be registered in a blockchain that records blocks based on data in each of a plurality of processing devices in a data processing system in which data is propagated or transformed via a plurality of processing devices. The verification device may include a verification unit that verifies the target block based on an upstream block that has already been registered in the blockchain. The verification device may include a verification response unit that supplies a verification result for the target block to a target verification device that is a supplier of the target block, and responds to a verification request for the target block. The verification device may include a registration unit that registers the target block in the blockchain in accordance with the verification result.

The verification device may further include an output unit that outputs an abnormality message if verification of the target block fails.

The verification device may further include a decoding unit that decodes the target block in accordance with the target verification device.

The verification response unit may determine whether it is the main verification device that should supply the verification results, and if so, may supply the verification results for the target block to the target verification device.

The data processing system may be a control system that controls a control target based on control parameters generated via the multiple processing devices. The verification response unit may determine that it is a main verification device when a controller that issues a control command to the control target according to the control parameters is a management target.

The verification device may further include a calculation unit that calculates a hash value based on an upstream block that has been registered in the blockchain. The verification unit may verify the target block based on the hash value included in the target block and the calculated hash value.

In a fifth aspect of the present invention, there is provided a verification method. The verification method may comprise, in a data processing system in which data is propagated or transformed via a plurality of processing devices, acquiring a target block to be registered in a blockchain that records blocks based on data in each of the plurality of processing devices. The verification method may comprise verifying the target block based on an upstream block already registered in the blockchain. The verification method may comprise supplying a verification result for the target block to a target verification device that is a supplier of the target block, and responding to a verification request for the target block. The verification method may comprise registering the target block in the blockchain in response to the verification result.

In a sixth aspect of the present invention, a verification program is provided. The verification program may be executed by a computer. The verification program may cause the computer to function as a block acquisition unit that acquires a target block to be registered in a blockchain that records blocks based on data in each of a plurality of processing devices in a data processing system in which data is propagated or converted via a plurality of processing devices. The verification program may cause the computer to function as a verification unit that verifies the target block based on an upstream block that has already been registered in the blockchain. The verification program may cause the computer to function as a verification response unit that responds to a verification request for the target block by supplying a verification result for the target block to a target verification device that is a supplier of the target block. The verification program may cause the computer to function as a registration unit that registers the target block in the blockchain in accordance with the verification result.

Note that the above summary of the invention does not list all of the features of the present invention. Also, subcombinations of these features may also be inventions.

An example of a data processing system 10 to which the verification technique according to the present embodiment may be applied is shown. 1 shows an example of a block diagram of a processing device 100. A control system 20 is shown as a specific example of a data processing system 10 to which the verification technique according to the present embodiment may be applied. 1 shows an example of a verification system 30 according to the present embodiment. An example of a blockchain registered in the verification system 30 according to this embodiment is shown. 1 shows an example of a block diagram of a verification device 300 according to the present embodiment. 13 shows an example of the flow of operations in the verification device 300 requesting verification. 13 shows an example of the flow of operations in the verification device 300 responding to a verification request. 1 shows an example of an operational flow in the processing device 100. An example of a computer 9900 is shown in which aspects of the present invention may be embodied in whole or in part.

The present invention will be described below through embodiments of the invention, but the following embodiments do not limit the invention according to the claims. Furthermore, not all of the combinations of features described in the embodiments are necessarily essential to the solution of the invention.

Figure 1 shows an example of a data processing system 10 to which the verification technique according to this embodiment may be applied. In the data processing system 10, various data are traded between various devices. In this figure, as an example, a case is shown in which multiple processing devices 100a to 100f (collectively referred to as "processing devices 100") are connected in a ring shape in the data processing system 10, and data is propagated in a loop shape between the multiple processing devices 100 (for example, processing device 100a → 100b → 100c → 100d → 100e → 100f → 100a → ...).

Here, the loop before the loop is defined as "upstream" and the loop after the loop is defined as "downstream". That is, for example, for processing device 100b, processing device 100a corresponds to the upstream processing device 100, and processing device 100c corresponds to the downstream processing device 100. At least one of such multiple processing devices 100 may convert input data by processing the input data input from the upstream processing device 100, and output the converted data as output data to the downstream processing device 100. The verification technique according to this embodiment may be applied to a data processing system 10 in which data is propagated or converted via such multiple processing devices 100.

Figure 2 shows an example of a block diagram of the processing device 100. The processing device 100 trades data with the upstream processing device 100 and with the downstream processing device 100, for example, using a public key cryptosystem (PKI: Public Key Infrastructure). Here, in a case where two parties trade data using a public key cryptosystem, the data receiver has obtained the public key of the data sender, i.e., the upstream processing device 100, in advance using a trusted certificate authority or the like. From here on, an example will be described in which the processing device 100 is processing device 100b. Processing device 100b has obtained the public key of processing device 100a, the upstream processing device 100, in advance.

The processing device 100 comprises a receiving unit 110, a decrypting unit 120, a processing unit 130, an encryption unit 140, a transmitting unit 150, and a continuation determination unit 160. Note that these blocks are functionally separated functional blocks, and do not necessarily correspond to the actual device configuration. In other words, just because they are shown as one block in this diagram, it does not necessarily mean that they are configured by one device. Also, just because they are shown as separate blocks in this diagram, it does not necessarily mean that they are configured by separate devices.

The receiving unit 110 receives data from the processing device 100a, which is the upstream processing device 100. In doing so, the processing device 100a processes the content to be transmitted using a hash function to calculate a hash value. The processing device 100a then transmits the ciphertext of the hash value, which is the hash value encrypted with its own private key, and the transmission content as a signature to the processing device 100b. The receiving unit 110 of the processing device 100b receives the data encrypted by the processing device 100a in this manner from the processing device 100a. The receiving unit 110 supplies the received data to the decryption unit 120.

The receiving unit 110 also receives messages from the verification device, which will be described later. The receiving unit 110 supplies the received messages to the continuation determination unit 160.

The decryption unit 120 decrypts the data. The decryption unit 120 extracts the encrypted hash value from the data supplied from the receiving unit 110. The decryption unit 120 then uses the public key of the processing device 100a to decrypt the encrypted hash value and obtain a hash value. The decryption unit 120 also extracts the transmission content of the processing device 100a from the data supplied from the receiving unit 110. The decryption unit 120 then processes the transmission content of the processing device 100a with the same hash function as the processing device 100a to calculate a hash value. The decryption unit 120 compares the decrypted hash value with the calculated hash value, and if the two match, determines that the data supplied from the receiving unit 110 is correct (not tampered with). In response, the decryption unit 120 supplies the transmission content of the processing device 100a to the processing unit 130.

The processing unit 130 processes the data. The processing unit 130 processes the data using the transmission contents of the processing device 100a supplied from the decryption unit 120 as input data. The processing unit 130 then supplies the output data, which is the result of processing the input data, to the encryption unit 140 as the transmission contents to be transmitted by the processing unit 130.

The encryption unit 140 encrypts the data. The encryption unit 140 processes the transmission content supplied from the processing unit 130 with a hash function to calculate a hash value. The encryption unit 140 then generates data in which the transmission content and the ciphertext of the hash value, which is the hash value encrypted with the encryption unit's own private key, are used as a signature. The encryption unit 140 supplies the data encrypted in this way to the transmission unit 150.

The transmission unit 150 transmits data to the processing device 100c, which is the downstream processing device 100. When a permission notification is provided from the continuation determination unit 160 described below, the transmission unit 150 transmits data encrypted by the encryption unit 140 to the processing device 100c. On the other hand, when a stop instruction is provided from the continuation determination unit 160, the transmission unit 150 stops transmitting data to the processing device 100c.

The continuation determination unit 160 determines whether to continue the data transaction. The continuation determination unit 160 determines whether to continue data transmission to the downstream processing device 100 according to a message from the verification device supplied from the receiving unit 110. For example, when a message indicating that the verification was successful is supplied, the continuation determination unit 160 determines to continue data transmission to the downstream processing device 100. Then, the continuation determination unit 160 supplies a permission notification to the transmitting unit 150 to permit transmission. In response, the transmitting unit 150 transmits encrypted data to the processing device 100c. On the other hand, when an abnormality message is supplied, the continuation determination unit 160 determines to stop data transmission to the downstream processing device 100. Then, the continuation determination unit 160 supplies a stop instruction to the transmitting unit 150 to stop transmission. In response, the transmitting unit 150 stops data transmission to the processing device 100c.

Figure 3 shows a control system 20 as a specific example of a data processing system 10 to which the verification technique according to this embodiment may be applied. From here on, a case will be described as an example in which the data processing system 10 is a control system 20 that controls a control target based on control parameters generated via multiple control processing devices 200. However, this is not limited to this. As described above, the verification technique according to this embodiment may be applied to various data processing systems 10 that are different from the control system 20.

In the control system 20 shown in this figure, the edge device 200a is used as the processing device 100a in the data processing system 10 in FIG. 1, the first calculation device 200b is used as the processing device 100b, the second calculation device 200c is used as the processing device 100c, the control parameter input device 200d is used as the processing device 100d, the controller 200e is used as the processing device 100e, and the control target 200f is used as the processing device 100f. Here, the edge device 200a, the first calculation device 200b, the second calculation device 200c, the control parameter input device 200d, and the controller 200e are collectively referred to as the "control processing device 200". Note that the configuration of the control processing device 200 is the same as that of the processing device 100 except for the configuration specific to each control processing device 200, so a description thereof will be omitted here.

In the control system 20, the edge device 200a, the control parameter input device 200d, the controller 200e, and the controlled object 200f belong to a control network that controls, for example, a plant. On the other hand, the first calculation device 200b and the second calculation device 200c belong to a non-control network, such as the Internet, that is outside the control network.

Examples of such plants include industrial plants such as chemical and bio plants, as well as plants that manage and control wellheads and surrounding areas of gas and oil fields, plants that manage and control hydroelectric, thermal and nuclear power generation, plants that manage and control environmental power generation such as solar and wind power, and plants that manage and control water supply and sewage systems and dams.

The edge device 200a collects status data (e.g., measurement data from multiple sensors installed in the plant) from the controlled object 200f. The edge device 200a then cleanses the status data and supplies only the necessary data to the non-controlled network (e.g., the first computing device 200b).

The first arithmetic device 200b belongs to a non-control network. The first arithmetic device 200b may be, for example, a SaaS (Software as a Service) provider. The first arithmetic device 200b acquires status data of the plant from the edge device 200a. Then, based on the status data, the first arithmetic device 200b generates first control data related to control parameters for controlling the control target 200f. The first arithmetic device 200b supplies the generated first control data to the second arithmetic device 200c.

The second computing device 200c, like the first computing device 200b, belongs to a non-controlled network and may be, for example, a SaaS provider. The second computing device 200c acquires first control data from the first computing device 200b. Then, based on the first control data, the second computing device 200c generates second control data related to control parameters for controlling the control target 200f. The second computing device 200c supplies the generated second control data to the control parameter input device 200d.

The control parameter input device 200d acquires the second control data from the second calculation device 200c. Then, the control parameter input device 200d supplies the control parameters based on the second control data to the controller 200e.

The controller 200e controls the control object 200f. The controller 200e may be, for example, a distributed control system (DCS). The controller 200e acquires control parameters from the control parameter input device 200d. The controller 200e then issues a control command based on the control parameters to the control object 200f.

The controlled object 200f is equipment and devices that are the subject of control. For example, the controlled object 200f may include actuators such as valves, pumps, heaters, fans, motors, and switches that control physical quantities such as pressure, temperature, pH, speed, and flow rate in the plant process. The controlled object 200f supplies plant status data to the edge device 200a in response to controlling the actuators in response to control commands from the controller 200e.

The verification technology according to this embodiment may be applied, as an example, to a control system 20 that controls a control target 200f based on control parameters generated via such multiple control processing devices 200a to 200e.

Figure 4 shows an example of a verification system 30 according to this embodiment. This figure shows an example in which the verification technique according to this embodiment is applied to the control system 20 in Figure 3. However, this is not limited to this. As described above, the verification technique according to this embodiment may be applied to various data processing systems 10 in which data is propagated or transformed via multiple processing devices 100.

As shown in this figure, the verification system 30 according to this embodiment includes multiple verification devices 300a to 300e (collectively referred to as "verification devices 300"). Here, the verification device 300a manages the edge device 200a, the verification device 300b manages the first calculation device 200b, the verification device 300c manages the second calculation device 200c, the verification device 300d manages the control parameter input device 200d, and the verification device 300e manages the controller 200e. In this way, the verification system 30 according to this embodiment may include multiple verification devices 300a to 300e, each of which manages multiple control processing devices 200a to 200e. Such multiple verification devices 300 are connected to each other so that they can communicate with each other via a network.

Figure 5 shows an example of a blockchain registered in the verification system 30 according to this embodiment. This figure shows that blocks a, b, c, and d are registered in chronological order in a chain. Here, for example, block a is a block based on data in an edge device 200a managed by the verification device 300a, block b is a block based on data in a first calculation device 200b managed by the verification device 300b, block c is a block based on data in a second calculation device 200c managed by the verification device 300c, and block d is a block based on data in a control parameter input device 200d managed by the verification device 300d.

For example, block b includes the hash value of block a, which is an upstream block, and the input data and output data of the first arithmetic device 200b. Similarly, block c includes the hash value of block b, which is an upstream block, and the input data and output data of the second arithmetic device 200c. Similarly, block d includes the hash value of block c, which is an upstream block, and the input data and output data of the control parameter input device 200d. In this way, in a blockchain, in addition to the input/output data of each of the multiple control processing devices 200, each block includes a hash value based on the contents of the block generated one block before, and these blocks are recorded in chronological order. In such a blockchain, if an attempt is made to tamper with data in a block registered in the past, the hash value calculated from the tampered block will be different from the previous one, so the hash values in all subsequent blocks must also be changed. For this reason, it can be said that the blockchain has a data structure that is highly resistant to tampering. The verification technique according to this embodiment may verify data registered in such a blockchain.

Figure 6 shows an example of a block diagram of a verification device 300 according to this embodiment. The verification device 300 according to this embodiment cooperates with other verification devices 300 to verify data in the entire control system 20, sequentially changing its role between "the side requesting verification" and "the side responding to the verification request" as data is propagated or converted via multiple control processing devices 200 in the control system 20. This will be described in detail.

The verification device 300 may be a computer such as a PC (personal computer), a tablet computer, a smartphone, a workstation, a server computer, or a general-purpose computer, or may be a computer system to which multiple computers are connected. Such a computer system is also a computer in the broad sense. The verification device 300 may be implemented by a virtual computer environment in which one or more programs can be executed within a computer. Alternatively, the verification device 300 may be a dedicated computer designed for verifying data, or may be dedicated hardware realized by a dedicated circuit. Furthermore, if the verification device 300 can be connected to the Internet, the verification device 300 may be realized by cloud computing.

The verification device 300 may also be an extension of an existing computer so that the existing computer can execute the verification function according to this embodiment by executing a verification program. In particular, the verification device 300 may be an add-on to each of the multiple control processing devices 200 included in the control system 20.

The verification device 300 includes a registration unit 310, a data acquisition unit 315, a calculation unit 320, a block generation unit 325, an encryption unit 330, a verification request unit 335, a verification result acquisition unit 340, an output unit 345, a block acquisition unit 350, a decryption unit 355, a verification unit 360, and a verification response unit 365. Note that these blocks are functionally separated functional blocks, and do not necessarily correspond to the actual device configuration. In other words, just because they are shown as one block in this diagram, it does not necessarily mean that they are configured by one device. Also, just because they are shown as separate blocks in this diagram, they do not necessarily mean that they are configured by separate devices.

Of the above blocks, the data acquisition unit 315, block generation unit 325, encryption unit 330, and verification request unit 335 mainly provide functions of the "side requesting verification." On the other hand, of the above blocks, the block acquisition unit 350, decryption unit 355, verification unit 360, and verification response unit 365 mainly provide functions of the "side responding to a verification request." And, of the above blocks, the registration unit 310, calculation unit 320, verification result acquisition unit 340, and output unit 345 provide functions of both the "side requesting verification" and the "side responding to a verification request." First, the functional blocks in the verification device 300 of the "side requesting verification" will be described.

The registration unit 310 registers and records blocks based on data in each of the multiple control processing devices 200 in the blockchain. The registration unit 310 also registers the target block in the blockchain according to the verification result described below.

In a data processing system 10 in which data is propagated or converted via multiple processing devices 100, the data acquisition unit 315 acquires target data, which is data in the target processing device 100 to be managed. Taking the verification device 300b in FIG. 4 as an example, the data acquisition unit 315 acquires target data, which is data in the first arithmetic device 200b to be managed, in a control system 20 that controls a control target 200f based on control parameters generated via multiple control processing devices 200a to 200e. For example, the data acquisition unit 315 may acquire input data and output data in the first arithmetic device 200b as target data from the first arithmetic device 200b via a network. However, this is not limited to this. The data acquisition unit 315 may acquire such target data via an operator or via various memory devices, etc. The data acquisition unit 315 supplies the acquired target data to the block generation unit 325.

The calculation unit 320 calculates a hash value based on an upstream block that has already been registered in the blockchain. In the flow of the "party requesting verification," the calculation unit 320 supplies the calculated hash value to the block generation unit 325.

The block generation unit 325 generates a target block to be registered in a blockchain that records blocks based on data in each of the multiple control processing devices 200, based on the target data. For example, the block generation unit 325 generates a target block that includes the target data supplied from the data acquisition unit 315 and the hash value supplied from the calculation unit 320. The block generation unit 325 supplies the generated target block to the encryption unit 330. The block generation unit 325 also supplies the generated target block to the registration unit 310.

The encryption unit 330 encrypts the target block for each of the multiple verification devices 300. Here, it is assumed that all of the verification devices 300 on the "side responding to the verification request" have previously obtained the public key of the verification device 300 on the "side requesting verification" using a trusted certificate authority or the like. The public key already obtained by one of the verification devices 300 on the "side responding to the verification request" may be different from the public key already obtained by the other verification devices 300 on the "side responding to the verification request". In other words, each of the verification devices 300 on the "side responding to the verification request" may have obtained a different public key of the verification device 300 on the "side requesting verification". The encryption unit 330 encrypts the target block using each private key corresponding to each public key already provided to each of the verification devices 300 on the "side responding to the verification request". The encryption unit 330 supplies the encrypted target block to the verification request unit 335.

The verification request unit 335 supplies the target block to a plurality of verification devices 300 that each manage a plurality of control processing devices 200, and requests verification of the target block. At this time, for example, the verification request unit 335 may supply each of the target blocks encrypted for each of the plurality of verification devices 300 to each of the plurality of verification devices 300.

The verification result acquisition unit 340 acquires the verification results for the target block from at least one of the multiple verification devices 300. For example, the verification result acquisition unit 340 may acquire the verification results for the target block from at least one of the verification devices 300 via a network. However, this is not limited to this. The verification result acquisition unit 340 may acquire such verification results via an operator, or via various memory devices, etc. In the flow of the "side requesting verification," the verification result acquisition unit 340 supplies the acquired verification results to the block generation unit 325 and the output unit 345.

The output unit 345 outputs according to the verification result. In the flow of the "side requesting verification", for example, when a verification result indicating that the verification is successful is obtained, the output unit 345 outputs a message indicating that the verification is successful to the control processing device 200 under management (for example, in the case of the verification device 300b, the first arithmetic device 200b). On the other hand, when a verification result indicating that the verification of the target block has failed is obtained, the output unit 345 outputs an abnormality message. In this case, the output unit 345 may, for example, notify the administrator of the verification system 30 that the verification of the target block has failed by issuing an alarm. The output unit 345 may also output a message indicating that the verification has failed to the control processing device 200 under management. However, this is not limited to this. The output unit 345 may output the verification result for the target block by displaying it on a monitor, by printing it out, or by transmitting it to another device.

So far, we have explained the functional blocks in the verification device 300 on the "side requesting verification". Next, we will explain the functional blocks in the verification device 300 on the "side responding to the verification request". As mentioned above, the registration unit 310, calculation unit 320, verification result acquisition unit 340, and output unit 345 provide the functions of both the "side requesting verification" and the "side responding to the verification request".

As described above, the registration unit 310 registers and records blocks based on the data in each of the multiple control processing devices 200 in the blockchain. In addition, the registration unit 310 registers the target block in the blockchain according to the verification result described below.

In a data processing system 10 in which data is propagated or transformed via a plurality of processing devices 100, the block acquisition unit 350 acquires a target block to be registered in a blockchain that records blocks based on data in each of the plurality of processing devices 100. Taking the verification device 300e in FIG. 4 as an example, the block acquisition unit 350 acquires, for example, a target block based on target data in the first arithmetic device 200b to be verified from the verification device 300b that manages the first arithmetic device 200b in the control system 20 that controls the control target 200f based on control parameters generated via a plurality of control processing devices 200a to 200e. Note that such a target block includes the target data in the first arithmetic device 200b to be verified and the hash value of block a, which is an upstream block, as described above. The block acquisition unit 350 may acquire such a target block from the verification device 300b, for example, via a network. However, this is not limited to this. The block acquisition unit 350 may acquire such a target block via an operator or via various memory devices, etc. The block acquisition unit 350 supplies the acquired target block to the decoding unit 355.

The decryption unit 355 decrypts the target block according to the target verification device 300 that supplied the target block. Here, it is assumed that the verification device 300 that "responds to the verification request" has obtained the public keys of all the verification devices 300 that "request verification" in advance, using a trusted certificate authority or the like. The decryption unit 355 decrypts the target block using the public key of the target verification device 300 that supplied the target block. The decryption unit 355 supplies the decrypted target block to the verification unit 360. The decryption unit 355 also supplies the decrypted target block to the registration unit 310.

As described above, the calculation unit 320 calculates a hash value based on an upstream block that has already been registered in the blockchain. In the flow of the "side that responds to a verification request," the calculation unit 320 supplies the calculated hash value to the verification unit 360.

The verification unit 360 verifies the target block based on the upstream block that has already been registered in the blockchain. For example, the verification unit 360 verifies the target block based on the hash value included in the target block and the calculated hash value. The verification unit 360 supplies the verification result for the target block to the output unit 345 and the verification response unit 365.

The verification response unit 365 responds to a verification request for the target block by supplying the verification result for the target block to the target verification device that supplied the target block. The verification response unit 365 also supplies the verification result for the target block to the decryption unit 355.

As described above, the verification result acquisition unit 340 acquires the verification result for the target block from at least one of the multiple verification devices 300. In the flow of the verification device 300 that is "responding to the verification request," the verification result acquisition unit 340 supplies the acquired verification result to the decryption unit 355.

As described above, the output unit 345 outputs according to the verification result. In the flow of the "side responding to the verification request", the output unit 345 outputs an abnormality message if the verification of the target block fails. At this time, the output unit 345 may, for example, notify the administrator of the verification system 30 that the verification of the target block has failed by issuing an alarm. The output unit 345 may also output a message to the effect that the verification has failed to the control processing device 200 under management (for example, the controller 200e in the case of the verification device 300e).

From here on, the operation of the verification device 300 according to this embodiment will be explained in detail using a flow chart for each of the "side requesting verification" and "side responding to the verification request."

Figure 7 shows an example of the operation flow of the verification device 300 requesting verification. Here, we will explain an example in which the verification device 300 requesting verification is the verification device 300b that manages the first computing device 200b, and block b is the target block to be registered in the blockchain. Note that block a, which is the upstream block, has already been registered in the blockchain.

In step 710, the verification device 300 acquires the target data. For example, the data acquisition unit 315 acquires the target data, which is data in the target processing device 100 to be managed, in a data processing system 10 in which data is propagated or converted via multiple processing devices 100. As an example, the data acquisition unit 315 in the verification device 300b acquires as the target data the data in the first calculation device 200b to be managed in a control system 20 that controls the control target 200f based on control parameters generated via multiple control processing devices 200a to 200e.

At this time, the data acquisition unit 315 may acquire, as input data, the transmission contents of the edge device 200a supplied from the decryption unit 120 to the processing unit 130 in the first calculation device 200b. The data acquisition unit 315 may also acquire, as output data, the transmission contents of the first calculation device 200b supplied from the processing unit 130 to the encryption unit 140 in the first calculation device 200b. In this way, the data acquisition unit 315 may acquire, as target data, input data input from the upstream processing device 100 in the target processing device 100 and output data output to the downstream processing device 100. The data acquisition unit 315 supplies the acquired target data to the block generation unit 325.

In step 720, the verification device 300 calculates a hash value. For example, the calculation unit 320 calculates a hash value based on an upstream block that has already been registered in the blockchain. In this case, the target block to be registered in the blockchain is block b, so the calculation unit 320 in the verification device 300b performs hash processing on block a, which is the upstream block, to calculate the hash value of block a. The calculation unit 320 supplies the calculated hash value to the block generation unit 325.

In step 730, the verification device 300 generates a target block. For example, the block generation unit 325 generates a target block to be registered in a blockchain that records blocks based on data in each of the multiple control processing devices 200, based on the target data. More specifically, the block generation unit 325 generates a target block including the target data acquired in step 710 and the hash value calculated in step 720. As an example, the block generation unit 325 in the verification device 300b generates a target block b including the input data and output data in the first calculation device 200b, and the hash value of block a. The block generation unit 325 supplies the generated target block to the encryption unit 330.

In step 740, the verification device 300 encrypts the target block. For example, the encryption unit 330 encrypts the target block for each of the multiple verification devices 300. As an example, the encryption unit 330 in the verification device 300b encrypts the target block using each private key corresponding to the public key that has been provided to each of the multiple verification devices 300a, 300c, 300d, and 300e. The encryption unit 330 supplies the encrypted target block to the verification request unit 335.

In step 750, the verification device 300 requests verification of the target block. For example, the verification request unit 335 supplies the target block to multiple verification devices 300 that each manage multiple control processing devices 200, and requests verification of the target block. As an example, the verification request unit 335 in the verification device 300b supplies each of the target blocks encrypted for each of the multiple verification devices 300a, 300c, 300d, and 300e to each of the multiple verification devices 300a, 300c, 300d, and 300e.

In step 760, the verification device 300 determines whether or not a verification result has been acquired. For example, the verification result acquisition unit 340 determines whether or not a verification result has been acquired from at least one of the multiple verification devices 300. As an example, the verification result acquisition unit 340 in the verification device 300b determines whether or not a verification result has been acquired from at least one of the multiple verification devices 300a, 300c, 300d, and 300e. If it is determined in step 760 that a verification result has not been acquired (No), the verification device 300 returns the process to step 760 and continues the flow. If it is determined in step 760 that a verification result has been acquired (Yes), the verification device 300 proceeds to step 765.

In step 765, the verification device 300 determines whether the verification result indicates that the verification was successful. For example, the verification result acquisition unit 340 determines whether the verification result acquired in step 760 indicates that the verification was successful. As an example, the verification result acquisition unit 340 in the verification device 300b determines whether the verification result acquired from at least one of the multiple verification devices 300a, 300c, 300d, and 300e indicates that the verification was successful. If it is determined in step 765 that the verification is successful (Yes), the verification result acquisition unit 340 supplies the verification result acquired in step 760 to the block generation unit 325 and the output unit 345. Then, the verification device 300 proceeds to step 770.

In step 770, the verification device 300 registers the target block in the blockchain. As an example, when a verification result indicating that the verification was successful is supplied, the block generation unit 325 in the verification device 300b supplies block b, which is the target block generated in step 730, to the registration unit 310. In response, the registration unit 310 registers block b at the end of the blockchain (after block a). In this way, the registration unit 310 registers the target block in the blockchain in response to the verification result from at least one of the multiple verification devices 300.

In step 775, the verification device 300 outputs a message indicating that the verification was successful. As an example, when the output unit 345 in the verification device 300b receives a verification result indicating that the verification was successful, the output unit 345 outputs a message indicating that the verification was successful to the first calculation device 200b that it manages. In response to this, the first calculation device 200b determines to continue sending data to the downstream control processing device 200, and sends data to the second calculation device 200c.

On the other hand, if it is determined in step 765 that the verification has failed (No), the verification result acquisition unit 340 supplies the verification result acquired in step 760 to the output unit 345. Then, the verification device 300 advances the process to step 780.

In step 780, the verification device 300 issues an alarm. As an example, the output unit 345 in the verification device 300b issues an alarm to notify the administrator of the verification system 30 that the verification of the target block, block b, has failed.

In step 785, the verification device 300 outputs an abnormality message. As an example, when the output unit 345 in the verification device 300b obtains a verification result indicating that the verification of the target block has failed, the output unit 345 outputs an abnormality message to the first calculation device 200b that it manages. In response to this, the first calculation device 200b determines to stop sending data to the downstream control processing device 200, and stops sending data to the second calculation device 200c.

Figure 8 shows an example of the operation flow of the verification device 300 that responds to the verification request. Here, the verification device 300 that responds to the verification request is the verification device 300e that manages the controller 200e, and an example is explained in which block b from the verification device 300b is the target block to be registered in the blockchain. Note that block a, which is the upstream block, is already registered in the blockchain.

In step 810, the verification device 300 acquires the target block. For example, in a data processing system 10 in which data is propagated or transformed via multiple processing devices 100, the block acquisition unit 350 acquires a target block to be registered in a blockchain that records blocks based on data in each of the multiple processing devices 100. As an example, in a control system 20 that controls a control target 200f based on control parameters generated via multiple control processing devices 200a to 200e, the block acquisition unit 350 in the verification device 300e acquires block b based on data in the first calculation device 200b to be verified as a target block from the verification device 300b that manages the first calculation device 200b. The block acquisition unit 350 supplies the acquired target block to the decryption unit 355.

In step 815, the verification device 300 decrypts the target block. For example, the decryption unit 355 decrypts the target block acquired in step 810 according to the target verification device 300 that is the source of the target block. As an example, the decryption unit 355 in the verification device 300e decrypts the target block b acquired from the verification device 300b using the public key of the verification device 300b. The decryption unit 355 supplies the decrypted target block to the verification unit 360.

In step 820, the verification device 300 calculates a hash value. For example, the calculation unit 320 calculates a hash value based on an upstream block that has already been registered in the blockchain. In this case, the target block to be registered in the blockchain is block b, so the calculation unit 320 in the verification device 300e performs a hash process on block a, which is the upstream block, to calculate the hash value of block a. The calculation unit 320 supplies the calculated hash value to the verification unit 360.

In step 830, the verification device 300 determines whether the hash values match. For example, the verification unit 360 compares the hash value included in the target block decrypted in step 815 with the hash value calculated in step 820. If the hash values match, the verification unit 360 determines that the verification of the target block has been successful. On the other hand, if the hash values do not match, the verification unit 360 determines that the verification of the target block has failed. As an example, the verification unit 360 in the verification device 300e compares the hash value included in the decrypted block b with the calculated hash value of the block a. If the hash values match, the verification unit 360 determines that the verification of the target block, block b, has been successful. On the other hand, if the hash values do not match, the verification unit 360 determines that the verification of the target block, block b, has failed. That is, the verification unit 360 verifies the target block based on the hash value included in the target block and the calculated hash value. In this way, the verification unit 360 verifies the target block based on the upstream block that has been registered in the blockchain.

If it is determined in step 830 that the hash values do not match (No), the verification unit 360 supplies a verification result indicating that the verification of the target block has failed to the output unit 345 and the verification response unit 365. Then, the verification device 300 proceeds to step 835.

In step 835, the verification device 300 issues an alarm. As an example, the output unit 345 in the verification device 300e issues an alarm to notify the administrator of the verification system 30 that the verification of the target block, block b, has failed.

In step 840, the verification device 300 outputs an abnormality message. As an example, if the verification of the target block fails, the output unit 345 in the verification device 300e outputs an abnormality message to the controller 200e that it manages. In response, the controller 200e determines to stop sending data to the downstream control processing device 200, and stops sending control commands to the control target 200f.

In step 845, the verification device 300 responds that the verification has failed. As an example, when a verification result indicating that the verification of the target block has failed is supplied, the verification response unit 365 in the verification device 300e supplies the verification result to the verification device 300b that supplied the target block. In this way, the verification response unit 365 supplies the verification result for the target block to the target verification device 300 that supplied the target block, and responds to the verification request for the target block.

On the other hand, if it is determined in step 830 that the hash values match (Yes), the verification unit 360 supplies the verification response unit 365 with a verification result indicating that the verification of the target block was successful. Then, the verification device 300 proceeds to step 850.

In step 850, the verification device 300 determines whether it is the main verification device. For example, the verification response unit 365 in the verification device 300e determines whether it is the main verification device that should supply the verification results among the multiple control processing devices 200. At this time, the verification response unit 365 may determine that it is the main verification device when the controller 200e that gives the control command according to the control parameter to the control object 200f is the object of management, as an example. In a control system that controls the control object 200f based on the control parameters generated via the multiple control processing devices 200a to 200e, the controller 200e that finally gives the control command to the control object 200f can be said to be the main device that bears responsibility for the entire control system. Therefore, the verification device 300e that manages such a controller 200e may be the main verification device that should supply the verification results. Note that when the verification device 300e becomes the "side that requests verification," one of the other verification devices 300 may operate as the main verification device. In the above description, an example has been given in which the verification device 300e mainly operates as the main verification device. However, this is not limited to this. Which of the multiple verification devices 300 is to be the main verification device may be determined according to a predefined algorithm, order, or the like. For example, the processing load may be distributed among the multiple verification devices 300 by rotating the main verification device.

If it is determined in step 850 that it is the main verification device (Yes), the verification device 300 proceeds to step 855.

In step 855, the verification device 300 registers the target block in the blockchain. As an example, if the verification response unit 365 in the verification device 300e determines that it is the main verification device, it supplies the decryption unit 355 with a verification result indicating that the verification was successful. The decryption unit 355 then supplies the target block decrypted in step 815 to the registration unit 310. In response to this, the registration unit 310 registers the target block, block b, at the end of the blockchain (after block a). In this way, the registration unit 310 registers the target block in the blockchain in accordance with the verification result.

In step 860, the verification device 300 responds that the verification was successful. As an example, the verification response unit 365 in the verification device 300e supplies the verification result indicating that the verification of the target block was successful to the verification device 300b, which is the supplier of the target block. In this way, the verification response unit 365 responds to the verification request for the target block by supplying the verification result for the target block to the target verification device 300, which is the supplier of the target block. In this way, the verification response unit 365 may determine whether it is the main verification device that should supply the verification result among the multiple verification devices 300, and if it is the main verification device, supply the verification result for the target block to the target verification device 300. In response to this, the registration unit 310 in the verification device 300b, which is the "side requesting verification," registers the target block in the blockchain in accordance with the verification result from the main verification device that should supply the verification result among the multiple verification devices 300.

On the other hand, if it is determined in step 850 that the verification device is not the main verification device (No), the verification device 300 proceeds to step 865.

In step 865, the verification device 300 determines whether or not it has acquired a verification result indicating that the verification was successful. As an example, the verification result acquisition unit 340 of the verification devices 300a, 300c, and 300d that are not the main verification device determines whether or not it has acquired a verification result indicating that the verification was successful from the verification device 300e that is the main verification device. In step 865, if the verification result indicating that the verification was successful has not been acquired (No), the verification device 300 returns the process to step 865 and continues the flow. That is, the verification devices 300a, 300c, and 300d that are not the main verification device wait for a verification result indicating that the verification was successful to be supplied from the verification device 300e that is the main verification device. On the other hand, if a verification result indicating that the verification was successful is acquired in step 865 (Yes), the verification result acquisition unit 340 supplies the acquired verification result to the decryption unit 355. Then, the verification device 300 advances the process to step 870.

In step 870, the verification device 300 registers the target block in the blockchain. As an example, when the decryption unit 355 in the verification devices 300a, 300c, and 300d that are not the main verification device receives a verification result indicating that the verification was successful, it supplies the target block decrypted in step 815 to the registration unit 310. In response, the registration unit 310 registers the target block, block b, at the end of the blockchain (after block a). In this way, the registration unit 310 registers the target block in the blockchain in accordance with the verification result.

Figure 9 shows an example of the flow of operations in the control processing device 200. Here, an example is described in which the control processing device 200 is the first calculation device 200b.

In step 910, the control processing device 200 receives data from upstream. As an example, the receiving unit 110 in the first arithmetic device 200b receives data from the edge device 200a, which is the upstream control processing device 200. In this case, the edge device 200a processes the content to be transmitted using a hash function to calculate a hash value. Then, the edge device 200a transmits the ciphertext of the hash value, which is the hash value encrypted with its own private key, and the transmission content as a signature to the first arithmetic device 200b. The receiving unit 110 in the first arithmetic device 200b receives the data encrypted by the edge device 200a in this way from the edge device 200a. The receiving unit 110 supplies the received data to the decryption unit 120.

In step 920, the control processing device 200 decrypts the data. As an example, the decryption unit 120 extracts the encrypted hash value from the data received in step 910. The decryption unit 120 then uses the public key of the edge device 200a to decrypt the encrypted hash value and obtain a hash value. The decryption unit 120 also extracts the transmission content of the edge device 200a from the data received in step 910. The decryption unit 120 then processes the transmission content of the edge device 200a with the same hash function as the edge device 200a to calculate a hash value. The decryption unit 120 compares the decrypted hash value with the calculated hash value, and if the two match, determines that the data received in step 910 is correct (not tampered with). In response, the decryption unit 120 supplies the transmission content of the edge device 200a to the processing unit 130.

In step 930, the control processing device 200 processes the data. As an example, the processing unit 130 processes the data using the transmission content of the edge device 200a decrypted in step 920 as input data. The processing unit 130 then supplies the output data, which is the result of processing the input data, to the encryption unit 140 as the transmission content to be transmitted by the processing unit 130.

In step 940, the control processing device 200 provides input/output data. As an example, the processing unit 130 provides input data, which is the content transmitted by the edge device 200a, and output data, which is the content transmitted by itself, via the transmitting unit 150 to the verification device 300b that manages the first computing device 200b.

In step 950, the control processing device 200 encrypts the data. As an example, the encryption unit 140 uses a hash function to process the content to be sent, which is the result of the processing in step 930, to calculate a hash value. The encryption unit 140 then generates data in which the ciphertext of the hash value, obtained by encrypting the hash value with its own private key, and the content to be sent are used as a signature. The encryption unit 140 supplies the data encrypted in this manner to the transmission unit 150.

In step 960, the control processing device 200 determines whether or not a message has been acquired. As an example, the receiving unit 110 determines whether or not a message indicating a verification result has been received from the verification device 300b that manages the first calculation device 200b. If it is determined in step 960 that a message has not been acquired (No), the control processing device 200 returns the process to step 960 and continues the flow. On the other hand, if it is determined in step 960 that a message has been acquired (Yes), the receiving unit 110 supplies the received message to the continuation determination unit 160. Then, the control processing device 200 advances the process to step 970.

In step 970, the control processing device 200 determines whether the message indicates that the verification was successful. As an example, the continuation judgment unit 160 determines whether the message acquired in step 960 indicates that the verification was successful. If it is determined in step 970 that the verification was successful (Yes), the continuation judgment unit 160 determines to continue data transmission to the downstream control processing device 200, and supplies a permission notification to the transmission unit 150 indicating that data transmission to the downstream control processing device 200 is permitted. The control processing device 200 then proceeds to step 980.

In step 980, the control processing device 200 transmits the data downstream. As an example, in response to receiving the permission notification, the transmission unit 150 transmits the data encrypted in step 950 to the second calculation device 200c, which is the downstream control processing device 200.

On the other hand, if it is determined in step 970 that the verification has failed (No), the continuation determination unit 160 determines to stop transmitting data to the downstream control processing device 200, and supplies a stop instruction to the transmission unit 150 to stop transmitting data to the downstream control processing device 200. The control processing device 200 then advances the process to step 990.

In step 990, the control processing device 200 stops transmitting data downstream. As an example, in response to receiving the stop instruction, the transmission unit 150 stops transmitting the data encrypted in step 950 to the second calculation device 200c, which is the downstream control processing device 200.

In general data transactions, data integrity (mainly prevention of tampering) is achieved between two parties trading data using public key encryption (PKI) and PKI-based digital signatures. In this case, tampering by the trading partner can only be detected between two parties directly trading data. Therefore, in a system in which multiple devices participate in data transactions, tampering in devices that do not directly trade data cannot be detected. In general data verification, each of the multiple devices participating in data transactions records its own processing log, and when the system administrator performs an audit, the system administrator collects and examines the processing logs from each of the multiple devices individually, thereby achieving an audit trail. In this case, the integrity of the processing logs provided by each device depends on the provider, and the party conducting the audit cannot easily verify whether or not tampering has occurred.

In addition, with the spread of various cloud services, it is conceivable that external service providers such as SaaS providers will be used as at least some of the multiple devices that trade data. Such external service providers have various security levels, such as security policies, implementation formats, cloud server characteristics, reliability of the certification authority used, and communication channel VPN formats. Therefore, there is a risk of a tampering attack on the location with the lowest security level, which becomes a bottleneck and reduces the security level of the entire system that trades data. Therefore, it is desirable to reliably and easily realize tamper detection and audit trails for all devices participating in data trading as a whole system, without relying solely on digital signatures between two parties.

Therefore, the verification device 300 according to the present embodiment supplies the target block generated by itself to a plurality of verification devices 300 each managing other processing devices 100 in the data processing system 10, and requests verification of the target block. Then, the verification device 300 registers the target block in the blockchain according to the verification result from at least one of the plurality of verification devices 300. As a result, according to the verification device 300 according to the present embodiment, since the target block is verified and registered in the blockchain in cooperation with the other verification devices 300, it is possible to increase the difficulty of tampering with data in the entire verification system 30. As a result, according to the verification device 300 according to the present embodiment, even if data of a plant device is processed using a calculation service belonging to a non-control network, data tampering at each point of the data processing process can be detected, and an audit trail that cannot be deleted or rewritten can be left unified at each point.

Furthermore, the verification device 300 according to this embodiment outputs an abnormality message if the verification of the target block fails. As a result, according to the verification device 300 according to this embodiment, if data tampering is suspected, the administrator of the verification system 30 can be notified of this and data transactions in the data processing system 10 can be stopped. Therefore, according to the verification device 300 according to this embodiment, it is possible to prevent, for example, unintended control commands from being given to the control target.

In addition, the verification device 300 according to this embodiment encrypts the target block for each of the multiple verification devices 300. As a result, the verification device 300 according to this embodiment can maintain a high level of security even when the target block is transferred between multiple verification devices 300 for verification.

The verification device 300 according to this embodiment also registers the target block in the blockchain in response to the verification result from the main verification device. As a result, according to the verification device 300 according to this embodiment, the verification device 300 that supplies the verification result indicating the verification was successful can be limited to only the main verification device, so that the processing load on the verification system 30 as a whole can be reduced. In this case, such a main verification device may be a verification device 300e that manages a controller 200e that provides a control command according to a control parameter to a control target 200f. As a result, the verification device 300e that manages the controller 200e, which is the main device in the control system 20, can respond to the verification request on behalf of the controller 200e.

The verification device 300 according to this embodiment also generates a target block by including a hash value calculated based on an upstream block. As a result, the verification device 300 according to this embodiment can verify data while maintaining the excellent resistance to tampering that conventional blockchains have.

The verification device 300 according to this embodiment also generates input data and output data for the target processing device to be managed, including them in the target block. As a result, the verification device 300 according to this embodiment can determine at what stage the data was tampered with, even if data is converted in any of the processing devices 100 among multiple processing devices 100. Therefore, the verification device 300 according to this embodiment can analyze the cause and perform a follow-up investigation of each processing point, even if a problem occurs in a control parameter, for example.

In the above description, the verification system 30 includes a plurality of verification devices 300a to 300e that manage the control processing devices 200a to 200e, respectively. However, the number of verification devices 300 included in the verification system 30 is not limited to this. The verification system 30 may include a plurality of verification devices 300 that is greater than the plurality of control processing devices 200a to 200e. In this case, some of the verification devices 300 may function only as "those that respond to verification requests" without managing any of the control processing devices 200. This ensures redundancy of records for the entire verification system 30, further increasing the difficulty of tampering. Alternatively, the verification system 30 may include a plurality of verification devices 300 that is less than the plurality of control processing devices 200a to 200e. In other words, the plurality of verification devices 300 do not necessarily have to be provided in one-to-one correspondence with the plurality of control processing devices 200.

In the above description, a case where only the main verification device among the multiple verification devices 300 supplies a verification result indicating that the verification was successful has been shown as an example. However, this is not limited to this. Multiple verification devices 300 (e.g., all of the verification devices 300) among the verification device 300 "responding to the verification request" may supply a verification result indicating that the verification was successful. In this case, the verification device 300 "requesting verification" may determine that the verification of the target block has been successful if all of the obtained verification results indicate that the verification was successful. In other words, the verification device 300 "requesting verification" may determine that the verification of the target block has been successful if it unanimously obtains verification results indicating that the verification was successful from the verification devices 300 "responding to the verification request".

In the above description, an example was given in which the verification device 300 managed the edge device 200a, the first calculation device 200b, the second calculation device 200c, the control parameter input device 200d, and the controller 200e. However, this is not limited to this. The verification device 300 according to this embodiment may manage various devices that may collect data and supply it to other devices, such as gateway devices, firewall devices, communication routers, network switches, smart meters, IoT devices, IoT device control terminals, robots, process control devices, edge computers, and server computers.

Various embodiments of the present invention may be described with reference to flow charts and block diagrams, where a block may represent (1) a stage of a process in which an operation is performed or (2) a section of an apparatus responsible for performing an operation. Particular stages and sections may be implemented by dedicated circuitry, programmable circuitry provided with computer readable instructions stored on a computer readable medium, and/or a processor provided with computer readable instructions stored on a computer readable medium. Dedicated circuitry may include digital and/or analog hardware circuitry and may include integrated circuits (ICs) and/or discrete circuits. Programmable circuitry may include reconfigurable hardware circuitry including logical AND, logical OR, logical XOR, logical NAND, logical NOR, and other logical operations, memory elements such as flip-flops, registers, field programmable gate arrays (FPGAs), programmable logic arrays (PLAs), and the like.

A computer-readable medium may include any tangible device capable of storing instructions that are executed by a suitable device, such that the computer-readable medium having instructions stored thereon comprises an article of manufacture that includes instructions that can be executed to create means for performing the operations specified in the flowchart or block diagram. Examples of computer-readable media may include electronic storage media, magnetic storage media, optical storage media, electromagnetic storage media, semiconductor storage media, and the like. More specific examples of computer-readable media may include floppy disks, diskettes, hard disks, random access memories (RAMs), read-only memories (ROMs), erasable programmable read-only memories (EPROMs or flash memories), electrically erasable programmable read-only memories (EEPROMs), static random access memories (SRAMs), compact disk read-only memories (CD-ROMs), digital versatile disks (DVDs), Blu-ray (RTM) disks, memory sticks, integrated circuit cards, and the like.

The computer readable instructions may include either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages such as Smalltalk®, JAVA®, C++, etc., and conventional procedural programming languages such as the "C" programming language or similar programming languages.

The computer-readable instructions may be provided to a processor or programmable circuit of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, either locally or over a wide area network (WAN) such as a local area network (LAN), the Internet, etc., to execute the computer-readable instructions to create means for performing the operations specified in the flowcharts or block diagrams. Examples of processors include computer processors, processing units, microprocessors, digital signal processors, controllers, microcontrollers, etc.

10 shows an example of a computer 9900 in which aspects of the present invention may be embodied in whole or in part. A program installed on the computer 9900 may cause the computer 9900 to function as or perform operations associated with an apparatus according to an embodiment of the present invention or one or more sections of the apparatus, and/or to perform a process or steps of a process according to an embodiment of the present invention. Such a program may be executed by the CPU 9912 to cause the computer 9900 to perform certain operations associated with some or all of the blocks of the flowcharts and block diagrams described herein.

The computer 9900 according to this embodiment includes a CPU 9912, a RAM 9914, a graphics controller 9916, and a display device 9918, which are interconnected by a host controller 9910. The computer 9900 also includes input/output units such as a communication interface 9922, a hard disk drive 9924, a DVD drive 9926, and an IC card drive, which are connected to the host controller 9910 via an input/output controller 9920. The computer also includes legacy input/output units such as a ROM 9930 and a keyboard 9942, which are connected to the input/output controller 9920 via an input/output chip 9940.

The CPU 9912 operates according to the programs stored in the ROM 9930 and the RAM 9914, thereby controlling each unit. The graphics controller 9916 retrieves image data generated by the CPU 9912 into a frame buffer or the like provided in the RAM 9914 or into itself, and causes the image data to be displayed on the display device 9918.

The communication interface 9922 communicates with other electronic devices via a network. The hard disk drive 9924 stores programs and data used by the CPU 9912 in the computer 9900. The DVD drive 9926 reads programs or data from the DVD-ROM 9901 and provides the programs or data to the hard disk drive 9924 via the RAM 9914. The IC card drive reads programs and data from an IC card and/or writes programs and data to an IC card.

The ROM 9930 stores therein a boot program or the like that is executed by the computer 9900 upon activation, and/or a program that depends on the hardware of the computer 9900. The input/output chip 9940 may also connect various input/output units to the input/output controller 9920 via a parallel port, a serial port, a keyboard port, a mouse port, etc.

The programs are provided by a computer-readable medium such as a DVD-ROM 9901 or an IC card. The programs are read from the computer-readable medium and installed in the hard disk drive 9924, RAM 9914, or ROM 9930, which are also examples of computer-readable media, and executed by the CPU 9912. The information processing described in these programs is read by the computer 9900, and brings about cooperation between the programs and the various types of hardware resources described above. An apparatus or method may be constructed by realizing the manipulation or processing of information according to the use of the computer 9900.

For example, when communication is performed between the computer 9900 and an external device, the CPU 9912 may execute a communication program loaded into the RAM 9914 and instruct the communication interface 9922 to perform communication processing based on the processing described in the communication program. Under the control of the CPU 9912, the communication interface 9922 reads transmission data stored in a transmission buffer processing area provided in the RAM 9914, the hard disk drive 9924, the DVD-ROM 9901, or a recording medium such as an IC card, and transmits the read transmission data to the network, or writes reception data received from the network to a reception buffer processing area or the like provided on the recording medium.

The CPU 9912 may also cause all or a necessary portion of a file or database stored on an external recording medium such as a hard disk drive 9924, a DVD drive 9926 (DVD-ROM 9901), an IC card, etc. to be read into the RAM 9914, and perform various types of processing on the data on the RAM 9914. The CPU 9912 then writes back the processed data to the external recording medium.

Various types of information, such as various types of programs, data, tables, and databases, may be stored in the recording medium and undergo information processing. The CPU 9912 may perform various types of processing on the data read from the RAM 9914, including various types of operations, information processing, conditional judgment, conditional branching, unconditional branching, information search/replacement, etc., as described throughout this disclosure and specified by the instruction sequence of the program, and write back the results to the RAM 9914. The CPU 9912 may also search for information in a file, database, etc. in the recording medium. For example, if multiple entries each having an attribute value of a first attribute associated with an attribute value of a second attribute are stored in the recording medium, the CPU 9912 may search for an entry that matches a condition in which an attribute value of the first attribute is specified from among the multiple entries, read the attribute value of the second attribute stored in the entry, and thereby obtain the attribute value of the second attribute associated with the first attribute that satisfies a predetermined condition.

The above-described program or software module may be stored on a computer-readable medium on the computer 9900 or in the vicinity of the computer 9900. In addition, a recording medium such as a hard disk or RAM provided in a server system connected to a dedicated communication network or the Internet can be used as a computer-readable medium, thereby providing the program to the computer 9900 via the network.

The present invention has been described above using an embodiment, but the technical scope of the present invention is not limited to the scope described in the above embodiment. It is clear to those skilled in the art that various modifications and improvements can be made to the above embodiment. It is clear from the claims that forms with such modifications or improvements can also be included in the technical scope of the present invention.

The order of execution of each process, such as operations, procedures, steps, and stages, in the devices, systems, programs, and methods shown in the claims, specifications, and drawings is not specifically stated as "before" or "prior to," and it should be noted that the processes may be performed in any order, unless the output of a previous process is used in a later process. Even if the operational flow in the claims, specifications, and drawings is explained using "first," "next," etc. for convenience, it does not mean that it is necessary to perform the processes in this order.

10 Data processing system 100 Processing device 110 Receiving unit 120 Decrypting unit 130 Processing unit 140 Encrypting unit 150 Transmitting unit 160 Continuation judgment unit 20 Control system 200 Control processing device 200a Edge device 200b First arithmetic unit 200c Second arithmetic unit 200d Control parameter input device 200e Controller 200f Control target 30 Verification system 300 Verification device 310 Registration unit 315 Data acquisition unit 320 Calculation unit 325 Block generation unit 330 Encryption unit 335 Verification request unit 340 Verification result acquisition unit 345 Output unit 350 Block acquisition unit 355 Decrypting unit 360 Verification unit 365 Verification response unit 9900 Computer 9901 DVD-ROM
9910 Host controller 9912 CPU
9914 RAM
9916 Graphics controller 9918 Display device 9920 Input/output controller 9922 Communication interface 9924 Hard disk drive 9926 DVD drive 9930 ROM
9940 Input/Output Chip 9942 Keyboard

Claims (10)

A verification device among a plurality of verification devices that manage each of a plurality of processing devices in a data processing system in which data is propagated or transformed via the plurality of processing devices,
each of the plurality of verification devices acquires data in a processing device to be managed among the plurality of processing devices, and requests verification of a block based on the data;
The verification device, which is the one verification device,
a data acquisition unit that acquires target data, which is data in a target processing device to be managed;
A block generation unit that generates a target block to be registered in a blockchain that records blocks based on data in each of the plurality of processing devices, based on the target data;
a verification request unit that supplies the target block to another verification device among the plurality of verification devices and requests verification of the target block;
and a registration unit that registers the target block in the blockchain in response to a verification result from at least one other verification device among the plurality of verification devices. The verification device according to claim 1, further comprising an output unit that outputs an abnormality message when the verification result indicates that the verification of the target block has failed. an encryption unit that encrypts the target block for each of the plurality of verification devices;
3 . The verification device according to claim 1 , wherein the verification request unit supplies each of the target blocks encrypted for each of the other verification devices among the plurality of verification devices to each of the other verification devices among the plurality of verification devices. 4. The verification device according to claim 1, wherein the registration unit registers the target block in the blockchain in response to a verification result from a main verification device that is another verification device among the plurality of processing devices to which the verification result should be supplied. the data processing system is a control system that controls a control target based on control parameters generated via the plurality of processing devices;
5. The verification device according to claim 4, wherein the main verification device is another verification device that manages a controller that issues a control command to the control target according to the control parameters. A calculation unit that calculates a hash value based on an upstream block registered in the blockchain,
The verification device according to claim 1 , wherein the block generator generates the target block including the hash value. the data acquisition unit acquires input data input from an upstream processing device in the target processing device and output data to be output to a downstream processing device;
The verification device according to claim 1 , wherein the block generator generates the target block including the input data and the output data. A block acquisition unit that acquires other target blocks to be registered in the blockchain;
A verification unit that verifies the other target block based on an upstream block registered in the blockchain;
a verification response unit that supplies a verification result for the other target block to a target verification device that is a source of the other target block, and responds to a verification request for the other target block;
The verification device according to claim 1 , further comprising: 1. A verification method executed by one of a plurality of verification devices that manages a plurality of processing devices in a data processing system in which data is propagated or transformed via the plurality of processing devices, the method comprising:
each of the plurality of verification devices acquires data in a processing device to be managed among the plurality of processing devices, and requests verification of a block based on the data;
The verification method is as follows:
The one verification device acquires target data which is data in a target processing device to be managed;
The one verification device generates a target block to be registered in a blockchain that records blocks based on data in each of the multiple processing devices, based on the target data;
the one verification device supplies the target block to another verification device among the plurality of verification devices and requests verification of the target block;
The one verification device registers the target block in the blockchain in response to a verification result from at least one other verification device among the plurality of verification devices. A verification program executed by a computer to function as one of a plurality of verification devices that manages a plurality of processing devices in a data processing system in which data is propagated or transformed via the plurality of processing devices, the verification program comprising:
each of the plurality of verification devices acquires data in a processing device to be managed among the plurality of processing devices, and requests verification of a block based on the data;
The verification program includes:
a data acquisition unit that acquires target data, which is data in a target processing device to be managed;
A block generation unit that generates a target block to be registered in a blockchain that records blocks based on data in each of the plurality of processing devices, based on the target data;
a verification request unit that supplies the target block to another verification device among the plurality of verification devices and requests verification of the target block;
a verification program that causes the program to function as a registration unit that registers the target block in the blockchain in response to a verification result from at least one other verification device among the plurality of verification devices.

Images