ICS data trusted circulation system and method based on double-layer blockchain assistance

Abstract

The present invention discloses a double-layer blockchain-assisted ICS data trusted flow system and method, constructs a double-layer blockchain-assisted industrial control system data flow protection network framework; designs OT blockchain and IT blockchain to reconstruct the ICS network boundary. And divides the industrial control system nodes into device nodes i , workstation node g i and interaction node j i Three types of nodes. An identity-assisted authentication mechanism based on a Bloom filter and a trusted database was designed to quickly identify dishonest nodes. An ICS-RBAC zero-trust access control mechanism based on RBAC was designed to ensure zero-trust data interaction between OT blockchains, IT blockchains, and ICS physical devices. An active defense mechanism based on a combination of a heartbeat mechanism and blockchain intelligence was designed to detect dishonest nodes in real time. This invention can achieve trusted data flow protection for ICS in different scenarios and has strong applicability.

Description

Technical Field

[0001] The present invention belongs to the fields of new-generation information technologies such as blockchain, zero-trust access control, and industrial control system data network attack defense, and specifically relates to a double-layer blockchain-assisted industrial control system (ICS) data trusted flow system and method. Background Art

[0002] Industrial Control Systems (ICS), a core component of critical infrastructure, can be described as integrated systems that utilize automated control components, computers, and underlying sensor devices for real-time data acquisition, monitoring, and process control. With the advancement of information technology, the world is accelerating into a new era of interconnectedness. ICS, primarily within the field, has seen a gradual shift from traditional electromechanical systems to network-based digital systems. While this breaks down the information silos of traditional ICS, it also increases the risk of cyberattacks. According to the 2022 Industrial Control Security Report by Dragos and Honeywell, 80% of ICS systems in global industrial infrastructure have limited visibility into their Operational Technology (OT) networks, 53% have undisclosed or uncontrolled connections within their OT networks, and 54% lack user management separation between their Information Technology (IT) and OT networks. The cyberattack threat facing ICS systems has increased dramatically.

[0003] Because industrial control systems were initially designed with a focus on industrial production and processing, they prioritized efficiency and real-time performance, lacking defenses against cyberattacks. Considering that attacks against industrial control systems can not only disrupt the network environment but also directly attack underlying physical components, disrupting production activities and causing adverse consequences, traditional industrial control system security relies primarily on firewalls, antivirus software, physical / network isolation, and improved attack detection capabilities. While traditional ICS network protection methods have somewhat protected the flow of data within industrial control systems, their centralized control and storage, coupled with passive defenses, are highly susceptible to data tampering, loss, and leakage. Furthermore, research into traditional defenses has only led to the continuous expansion of virus and vulnerability databases, further complicating industrial control network intrusion detection systems. These systems are unable to effectively address new viruses, vulnerabilities, and attacks, making it difficult to ensure truly trusted data flow within industrial control systems.

[0004] Blockchain technology is a decentralized shared ledger that combines data blocks in a chain in chronological order into a specific data structure, and cryptographically guarantees that it cannot be tampered with or forged. Applying blockchain technology to industrial control systems can change the current pain points of industrial control systems, such as centralization, passive defense, and complex defense. Researchers have preliminarily explored the role of blockchain in network defense in industrial control systems, including the decentralization, identity authentication, permission distribution, and control of industrial control systems based on blockchain technology; using the high fault tolerance of blockchain to improve the robustness of industrial control systems; and providing a trusted execution environment for attack detection and data sharing in industrial control systems through block chain technology. The above research has preliminarily solved the network defense problem of traditional industrial control systems, but there are still certain challenges in the research:

[0005] (1) The boundaries between the OT network and IT network of industrial control systems (ICS) remain blurred. Although researchers have used blockchain to decentralize ICS defense, the industrial control network and information interaction network are deeply integrated, and the internal operation data flow of ICS and the external shared data flow are not isolated, which poses a certain threat to the private data security of industrial control systems and increases the risk of attack.

[0006] (2) Data access control for industrial control systems (ICS) is still relatively coarse-grained. Although researchers have explored blockchain-based ICS authentication and dynamic authorization, the threats faced by industrial control systems (ICS) include not only attacks at the digital network level but also at the physical device level. There is a lack of sustainable, dynamic zero-trust access control strategies for physical and data resources.

[0007] (3) The proactive defense of industrial control systems (ICS) is still insufficient. Scholars have explored the use of blockchain’s high fault tolerance and high-trust environment to provide basic conditions for ICS network attack detection and data sharing. However, this defense feature is passive detection, and the proactive defense of the entire ICS life cycle is insufficient. Summary of the Invention

[0008] To address the three major technical issues mentioned above—fuzzy OT and IT network boundaries, coarse-grained data access control, and a lack of proactive defense measures—the present invention provides a trusted ICS data transfer system and method based on a two-layer blockchain.

[0009] The technical solution adopted by the system of the present invention is: a two-layer blockchain-assisted ICS data trusted flow system, including a manufacturing execution layer, a process monitoring layer, a control network layer, and a field control layer. The system uses two layers of blockchain: the OT blockchain and the IT blockchain to achieve trusted data flow. The OT blockchain ledger represents the internal data flow of the ICS, while the IT blockchain ledger represents the data flow of information exchange between the ICS and the outside world.

[0010] The ICS node includes device nodes s i , workstation node g i and interaction node j i ;Device nodes i For the chain mapping of field control devices, the workstation node g i Including engineer workstation, operation station and operation and maintenance station, interactive node i is an external workshop node; the equipment node s i , register on the OT blockchain, return the corresponding certificate and unique hash H(p), and back up the certificate information in the IT blockchain consensus; the interactive node j i , register on the IT blockchain, return the corresponding certificate and unique hash H(p), and back up the certificate information in the OT blockchain consensus; the workstation node g i , which belongs to the relay node of OT blockchain and IT blockchain. After being on the OT blockchain, it is registered and on the IT blockchain, and returns the corresponding certificate and unique hash H(p).

[0011] Preferably, the device node s i When registering on the chain, the user Client first sends a registration request to the OT blockchain and sends the relevant registration information M i s OT blockchain nodes verify and vote through Raft consensus, and send the consensus results to physical devices for verification and matching; the physical devices return the verification result information to the OT blockchain and communicate with M i s Match and send the final consensus result to the certification center CA; the certification center CA will check the device node s i Generate a unique certificate, sign it, broadcast it, issue it to the physical device node and OT blockchain, and return the result to the user client; finally, broadcast the result of this registration request to the IT blockchain, and the IT blockchain will perform a distributed backup of the information through a round of broadcasting. The device node s i Register on the chain.

[0012] As a preference, the interaction node j iWhen registering on the blockchain, the user Client first sends a registration request to the IT blockchain and sends the relevant registration information M i j , the nodes in the IT blockchain use Raft consensus to send the consensus results to the certification center CA; the certification center CA signs and generates a unique certificate, issues the certificate, and broadcasts the consensus results to the OT blockchain nodes; the OT blockchain is broadcast to all nodes for backup after a round of broadcasting, and the results are returned to the user Client, the interaction node j i Register on the chain.

[0013] As a preference, the workstation node g i When registering on the chain, the user Client first sends a registration request to the OT blockchain and sends the relevant registration information M i g ; OT blockchain nodes use Raft to vote and consensus, and the OT blockchain consensus result R OT And registration information M i g Send it to the IT blockchain, and the IT blockchain nodes will vote and reach consensus through Raft, and the OT blockchain consensus result R OT And the IT blockchain consensus result R IT Send to the certification center CA; the certification center CA signs and generates a unique certificate, which is issued to the user Client, OT blockchain and IT blockchain, and workstation node g i Register on the chain.

[0014] The technical solution adopted by the method of the present invention is: a method for trusted ICS data transfer based on a double-layer blockchain, which uses a Bloom filter and a trusted database identity-assisted authentication mechanism to quickly identify dishonest nodes;

[0015] Through a credit point incentive mechanism, every node behavior is recorded, and real-time judgment, update, and settlement are performed. The OT blockchain ledger and IT blockchain ledger are divided into three trusted databases according to the three types of nodes, and a corresponding Bloom filter is designed for each trusted database. In the subsequent verification process, it is only necessary to verify whether the node is in the corresponding trusted database to determine whether the node's real-time identity is trustworthy.

[0016] The Bloom filter has an m-bit bit array containing n elements x i The set T of k Bloom filter heavy hash functions h k ; First, initialize and set the m bits of the Bloom filter to 0; then add elements and set the n elements to be added x in the set T 1,,,n Rehash function h using k Bloom filters 1,,,kHash, each element gets k bits in the Bloom filter and sets them to 1; when performing node authentication, the element to be queried x i Hash, that is, {h1(x i ),h2(x i ),,,h k-1 (x i ),h k (x i )}, get k bits. If these k bits are all 1, then the element is in the set T, otherwise it is not. After the node is first screened out, the node data is traversed and verified, and the node is specifically based on the path, information is extracted from the IT blockchain ledger and the OT blockchain ledger, and the node registration information is verified.

[0017] The present invention also provides an ICS data trusted flow method assisted by a two-layer blockchain, an ICS-RBAC zero-trust access control mechanism based on RBAC, and a policy library ST. Device nodes can only access OT blockchain ledgers, interactive nodes can only access IT blockchain ledgers, and workstation nodes can access both OT blockchain ledgers and IT blockchain ledgers; thus ensuring zero-trust data interaction between OT blockchains, IT blockchains, and ICS physical devices.

[0018] As a preference, the specific implementation of OT blockchain access control includes the following sub-steps:

[0019] (1) The subject sends a transaction Tx i To the OT access control contract OT-ACSC, the transaction contains the certificate CA i , Object ID i , operation content OP, real-time environmental factors EV i And real-time credit score Tr i , the message Tx i Hash it with SHA256 and use your own private key sk p Tx i Encrypt and generate digital signature Sig;

[0020] (2) OT-ACSC uses a dynamic identity authentication mechanism to verify the subject, including verifying the subject's certificate and determining whether it is in the trusted database;

[0021] (3) If the verification is successful, the dynamic identity authentication mechanism is called to verify the identity of the object, including verifying the object's certificate and determining whether it is in the trusted database;

[0022] (4) If the verification is successful, the OT access control decision contract OT-ADSC is called to match the policy library ST;

[0023] (5) If the permissions are met, authorization is performed and the matching result is returned to OT-ACSC;

[0024] (6) OT-ACSC will Tx i Use the object public key pk p Perform RSA encryption and Sig to send to the object, the device node sends it to the mapping node on the OT blockchain, and the object receives Tx i After Sig, use the object public key pk p Decrypt Sig to obtain Tx i The object then hashes the original message using the same hash function SHA256 and compares the generated hash value with the decrypted hash value; if the two hash values ​​match, the digital signature Sig is valid and Tx i Complete and from the sender; then use the object private key to decrypt and obtain And call the Oracle-Modbus TCP contract to issue data instructions to the on-site equipment;

[0025] (7) Object to Data Generate digital signature Sig, OT risk prevention and control contract OT-RPSC performs secondary verification on the object; in order to ensure the validity of the subject and object credit points, the time threshold Time is designed, and the time interval threshold is determined. Use RSA encryption and return it to the subject together with Sig and the result. The subject verifies and decrypts it, and then records it on the blockchain and updates the credit score.

[0026] As a preference, the specific implementation of IT blockchain access control includes the following sub-steps:

[0027] (1) User Send a transaction Tx i To the IT access control contract IT-ACSC, the transaction includes the certificate CA i , Object ID i , query content RP and real-time credit score Tr i , Tx i Hash it using SHA256 and use Public key sk p Tx i Encrypt and generate digital signature Sig;

[0028] (2) IT-ACSC Use dynamic identity authentication mechanism for verification, including verification The certificate is checked and whether it is in the trusted database;

[0029] (3) If the verification is successful, the dynamic identity authentication mechanism is called to verify the object Identity, including verification The certificate is checked and whether it is in the trusted database;

[0030] (4) If the verification is successful, the IT access control decision contract IT-ADSC is called to match the policy library ST;

[0031] (5) If the permissions are met, authorization is performed and the matching result is returned to IT-ACSC;

[0032] (6) IT-ACSC will Tx i use Public key pk p Perform RSA encryption and send to Sig Receive Tx i And after Sig, use The public key pk p Decrypt Sig to obtain Tx i The hash value of ; then, Hash the original message using the same hash function SHA256 and compare the generated hash value with the decrypted hash value; if the two hash values ​​match, the digital signature Sig is valid and Tx i Complete and from the sender; and then use The private key is used to decrypt and obtain the data

[0033] (7) Data Generate digital signature Sig, IT risk prevention and control contract IT-RPSC Perform secondary verification to ensure as well as The validity of credit points, design the time threshold Time, and make a threshold judgment on the time interval, and set Tx i return Use RSA encryption and return the result with Sig Verify and decrypt, and update blockchain records and credit points.

[0034] As a preferred implementation, the specific implementation of OT&IT cross-chain access control includes the following sub-steps:

[0035] (1) Request verification: The requester sends a transaction Tx i Give IT access control contract IT-ACSC or OT access control contract OT-ACSC; i Hash it using the SHA256 hash function and use the public key skp Tx i Encrypt and generate digital signature Sig;

[0036] (2) IT-ACSC or OT-ACSC verifies the requester using a dynamic identity authentication mechanism;

[0037] (3) If the verification is passed, the Raft consensus is used to select g i Node, and use dynamic identity authentication mechanism to verify the node, use credit points to verify g i Nodes are incentivized;

[0038] (4) If the verification is successful, the OT access control decision contract OT-ADSC or the IT access control decision contract IT-ADSC is called to match the policy library ST;

[0039] (5) If the permissions are met, authorization is performed and the matching result is returned to the OT-ADSC or IT-ACSC;

[0040] (6) IT-ACSC or OT-ACSC will Tx i Use g i Node public key pk p Perform RSA encryption and send it to the requester with Sig, g i Node receives Tx i And after Sig, the requester's public key pk p Decrypt Sig to obtain Tx i The hash value of g i The node hashes the original message using the same hash function SHA256 and compares the generated hash value with the decrypted hash value; if the two hash values ​​match, the digital signature Sig is valid and Tx i Complete and from the sender; then use the g i Node private key is used for decryption;

[0041] (7) Data extraction: g i The node transfers the OT blockchain or IT blockchain request across chains and i The nodes on the chain where the requested node is located use the Raft consensus mechanism to reach a consensus. After the consensus is reached, the data is encrypted using the RSA encryption algorithm and sent to the interactive node g. i ;

[0042] (8) Data verification: g i The data is verified using a dynamic identity authentication mechanism, including verifying the authenticity of the data and whether it has been tampered with;

[0043] (9) Data upload: g i The data and the data providing node are packaged into a transaction Tx i return , and upload data across chains;

[0044] (10) OT risk prevention and control contract OT-RPSC or IT risk prevention and control contract IT-RPSC i Perform secondary verification; in order to ensure the validity of the participating node credit points, design the time threshold Time, and make a threshold judgment on the time interval, and set Tx i return Use RSA encryption and return it to the requester together with Sig and the result. The requester verifies and decrypts it, and then records it on the blockchain and updates the credit score.

[0045] The present invention also provides a trusted ICS data transfer method based on a double-layer blockchain, an active defense mechanism based on the combination of a heartbeat mechanism and blockchain intelligence, and real-time detection of dishonest nodes.

[0046] The specific implementation includes the following sub-steps:

[0047] (1) Set the heartbeat test cycle time T h , and not greater than the T h In the process, a random challenge is sent to the node. The challenge is designed as follows: randomly select the historical test timestamp, set the challenge feedback time threshold T t ;

[0048] (2) According to the historical timestamp, query the corresponding blockchain ledger and randomly obtain data interaction request records;

[0049] (3) Call the data interaction record of both parties and compare it with the blockchain account data. If the data is in the specified T t If there is no reply within T, the node is judged as a problem node and artificial testing is carried out to distinguish between downtime, failure and forgery. t If the node responds and compares the results within 1 second, the node is a safe node;

[0050] (4) Update the credit values ​​of different types of nodes and mark them.

[0051] Equivalent to the prior art, the advantages of the present invention are:

[0052] (1) The double-layer blockchain-assisted industrial control system data trusted flow model and method established by the present invention is an attempt to combine multi-layer blockchain technology, zero-trust access control technology, artificial intelligence technology and industrial control systems. It is innovative and has certain guiding value for the subsequent expansion of this method to other Internet of Things systems and even other industries.

[0053] (2) The present invention can embed the blockchain system in the industrial control system through the customized design of the oracle, and redefine the network boundary between the OT and IT of the industrial control network by using a two-layer blockchain network.

[0054] (3) This invention customizes the design of ICS-RBAC zero-trust access control policies for physical devices and network node data, increases the granularity of network protection for data flow in industrial control systems, effectively protects industrial control data flows in ICS, and effectively resists various security threats and attacks.

[0055] (4) The present invention uses a Bloom filter and a trusted database to assist the industrial control system in identity authentication, thereby reducing the rapid exclusion of dishonest nodes and unauthorized nodes.

[0056] (5) This invention uses smart contract technology to design active defense measures for the entire ICS access cycle. Through the "blockchain-heartbeat mechanism-smart contract" design of "OT blockchain organization-IT blockchain organization" and "blockchain node-oracle-field equipment" node hidden credibility verification, a highly secure and controllable flow of industrial control system data is achieved, providing effective support for remote engineer operations and workshop data interaction.

[0057] (6) The present invention has strong applicability and can realize the trusted flow protection of data for industrial control systems in different scenarios, and has universal applicability. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] The technical solution of the present invention is further illustrated below using embodiments and specific implementation methods. In addition, some drawings are also used in the process of illustrating the technical solution. For those skilled in the art, other drawings and the intention of the present invention can be obtained based on these drawings without making any creative efforts.

[0059] Figure 1 is a system architecture diagram of an embodiment of the present invention;

[0060] Figure 2 A schematic diagram of a method according to an embodiment of the present invention;

[0061] Figure 3 This is a schematic diagram of a dynamic identity authentication mechanism (registration) according to an embodiment of the present invention;

[0062] Figure 4 A schematic diagram of a dynamic identity authentication mechanism (authentication) according to an embodiment of the present invention;

[0063] Figure 5 This is a schematic diagram of the ICS-RBAC access control mechanism according to an embodiment of the present invention;

[0064] Figure 6 This is a schematic diagram of the OT&IT cross-chain access control principle of an embodiment of the present invention;

[0065] Figure 7 This is a schematic diagram of the active defense mechanism according to an embodiment of the present invention;

[0066] Figure 8 This is a comparison chart of the time consumption for troubleshooting dishonest nodes in identity authentication according to an embodiment of the present invention;

[0067] Figure 9 This is a time consumption diagram of honest node-assisted verification for identity authentication according to an embodiment of the present invention;

[0068] Figure 10 This is a schematic diagram of chain code simulation and certificate simulation according to an embodiment of the present invention;

[0069] Figure 11 Schematic diagram of RSA private key and certificate (public key) simulation in an embodiment of the present invention;

[0070] Figure 12 A schematic diagram of the verification and public key extraction of a physical device node certificate of an industrial control system according to an embodiment of the present invention;

[0071] Figure 13 A schematic diagram of data decryption for physical device nodes in an industrial control system according to an embodiment of the present invention;

[0072] Figure 14 Schematic diagram of test results of an embodiment of the present invention. DETAILED DESCRIPTION

[0073] In order to facilitate ordinary technicians in this field to understand and implement the present invention, the present invention is further described in detail below with reference to the accompanying drawings and examples. It should be understood that the implementation examples described herein are only used to illustrate and explain the present invention and are not used to limit the present invention.

[0074] Because the field control layer and the field device layer are primarily connected via I / O serial ports and wiring, the data flow environment is relatively closed and secure. Therefore, the framework designed in this embodiment primarily covers the four layers of traditional industrial control systems: the manufacturing execution layer, the process monitoring layer, the control network layer, and the field control layer. Specifically, this embodiment customizes the design of a blockchain oracle. By contracting the Modbus protocol, it collects and uploads data from physical devices in real time, sends control instructions, and utilizes the blockchain network to securely protect the flowing data. Each module is described in detail below.

[0075] Industrial Control System Physical Device Module: This module primarily encompasses the interconnection between field control devices (PLCs, RTUs, PACs, etc.) and field equipment (actuators, sensors, field instruments, etc.), and the data exchange between field control devices and the blockchain network module. Communication between field control devices and field equipment is achieved through connections such as I / O serial ports. Information exchange between the industrial control system physical device module and the blockchain network module is achieved through the integration of oracles and industrial communication protocols such as Modbus.

[0076] Blockchain Network Module: The blockchain network module primarily consists of six components: model architecture, encrypted transmission, consensus mechanism, access control strategy, and defense measures. Regarding the model architecture, this embodiment designs a dual-channel, or two-tier, blockchain architecture: OT and IT. Both OT ledgers / contracts and IT ledgers / contracts are configured. Device nodes, workstation nodes, and interaction nodes are divided into three organizations: device nodes represent the on-chain mapping of field control devices; workstation nodes include engineer workstations, operation stations, and maintenance stations; and interaction nodes represent external workshop nodes. An initialization-sorting node is also included, responsible for generating the genesis block and sorting transaction processing. Regarding encrypted transmission and consensus mechanisms, data transmission on the blockchain uses the SHA256 algorithm, and the Raft algorithm is used for node consensus. Regarding access control strategy, an ICS-RBAC access control model is designed based on the RBAC zero-trust access control strategy to provide identity authentication, dynamic authorization, and dynamic access. Regarding defense measures, customized smart contracts are designed based on real-time data records (real-time behavior, credit points, instruction specifications, environmental factors, etc.), and a heartbeat mechanism is incorporated to provide adaptive and proactive network attack defense.

[0077] In industrial control system scenarios, eavesdroppers may attempt to eavesdrop on communication links between field devices and PLCs, between PLCs and engineer nodes, and between workshop interaction nodes in order to spy on industrial production, processing, and manufacturing data. Attackers may also disrupt physical device functionality, maliciously encrypt industrial data, maliciously consume ICS resources, and tamper with transmitted information (e.g., operating instructions, collected data). These attacks, such as worms, ransomware attacks, DoS attacks, and replay attacks, threaten the security of industrial control systems. In the adversary model of this embodiment, potential threats within the network are categorized as physical device-layer attacks and communication network-layer attacks.

[0078] Physical device layer attacks: Attackers can exploit vulnerabilities and weaknesses in industrial control systems (ICS) to embed viruses like industrial worms in control devices like PLCs, gaining partial or complete control of the ICS system. These viruses can then replicate and spread across the network, disrupting physical device functionality and maliciously consuming ICS resources. Therefore, the model must include granular permission management down to the physical device level and proactively prevent attackers from spreading malicious programs from ICS physical devices (such as USB ports and printers) to industrial control devices.

[0079] Communication network layer attacks: The first type of attack is an attack by malicious nodes on the OT blockchain. For example, malicious nodes (such as engineer workstations and operator stations) may be affected by undetected malware (such as ransomware) and eavesdrop on data by sending malicious commands, resulting in the loss of industrial data and damage to industrial control systems. Therefore, the model must fully arbitrate the flow of industrial data. The second type of attack is an attack by malicious nodes on the IT blockchain (such as workshop interaction nodes), launching some active attacks during the workshop data interaction process. For example, during the data interaction process, malicious nodes impersonate legitimate nodes in the network and launch some active attacks (such as DoS attacks and replay attacks), compromising the authenticity and integrity of industrial data.

[0080] Please see Figure 1 and Figure 2 This embodiment provides an ICS data trusted flow system based on a two-layer blockchain, including a manufacturing execution layer, a process monitoring layer, a control network layer, and a field control layer. The system uses two layers of blockchain, the OT blockchain and the IT blockchain, to implement trusted data flow. The OT blockchain ledger represents the internal data flow of the ICS, while the IT blockchain ledger represents the data flow for information exchange between the ICS and the outside world.

[0081] The ICS node includes device nodes s i , workstation node g i and interaction node j i ;Device nodes i For the chain mapping of field control devices, the workstation node g i Including engineer workstations, operation stations and maintenance stations, etc., interactive nodes i is an external workshop node; the equipment node s i , register on the OT blockchain, return the corresponding certificate and unique hash H(p), and back up the certificate information in the IT blockchain consensus; the interactive node j i , register on the IT blockchain, return the corresponding certificate and unique hash H(p), and back up the certificate information in the OT blockchain consensus; the workstation node g i, which belongs to the relay node of OT blockchain and IT blockchain. After being on the OT blockchain, it is registered and on the IT blockchain, and returns the corresponding certificate and unique hash H(p).

[0082] s i Nodes can only access the OT chain account book. During the registration process, s i The node is on the OT chain and the certificate information is backed up in the IT chain consensus. i Nodes can only access the IT chain account book. During the registration process, i The node is on the IT chain and the certificate information is backed up in the OT chain consensus. i The node is an intermediate connection node that can access OT and IT ledgers. It needs to be on the IT chain after being on the OT chain. The registration process is as follows: Figure 3 shown.

[0083] s i Node registration: Client first sends a registration request to the OT chain and sends relevant registration information M i s ={id i ,name i ,site i ,time i ,.....},OT chain nodes verify and vote through Raft consensus, and send the consensus results to physical devices such as PLC for verification and matching. PLC and other physical devices return the result information to the OT chain and communicate with M i s The nodes are matched and the final consensus result is sent to the CA. The CA generates a unique certificate for the node, signs it, broadcasts it, issues it to the physical device node and the OT chain, and returns the result to the client. Finally, the registration request result is broadcast to the IT chain. The IT chain performs a round of broadcasting to perform a distributed backup of the information, and the node is registered on the chain.

[0084] j i Node registration: Client first sends a registration request to IT Chain and sends relevant registration information The nodes in the IT chain use Raft consensus to send the consensus results to the CA. The CA signs and generates a unique certificate, issues the certificate, and broadcasts the consensus results to the OT chain nodes. After a round of broadcasting to all nodes for backup, the OT chain returns the results to the client, and the node is registered on the chain.

[0085] g i Node registration: g i The node is essentially a relay node for the OT chain and IT chain. The identity registration process is to send a registration request to the OT chain and send relevant registration information. OT chain nodes use Raft to vote and reach consensus, and the OT chain consensus result R OT and registration information Send to IT chain, IT chain nodes use Raft to vote and reach consensus, and the consensus result R OT And the consensus result R IT It is sent to the CA, which signs it and generates a unique certificate, which is then issued to the Client, OT chain, and IT chain. The node is then registered on the chain.

[0086] It contains multiple data factors such as the current status of the device, device IP, location information, running time, etc. With multiple data factors such as operator name, unique hash, location information, etc., M i j It has multiple data factors such as workshop location, position information, name, etc.

[0087] This example first reconstructs the ICS network boundary by integrating the OT and IT blockchains. Secondly, an identity-assisted authentication mechanism based on Bloom filters and a trusted database is designed to rapidly identify dishonest nodes. Finally, an ICS-RBAC zero-trust access control mechanism based on RBAC is designed to ensure zero-trust data interaction between the OT and IT blockchains and ICS physical devices. Finally, an active defense mechanism for the entire ICS access cycle is designed based on the heartbeat mechanism.

[0088] Please see Figure 4 This embodiment provides a trusted ICS data transfer method based on a two-layer blockchain. This method uses a Bloom filter and a trusted database identity authentication mechanism to quickly identify dishonest nodes. A credit point incentive mechanism records every node action, allowing for real-time judgment, update, and settlement. The OT and IT blockchain ledgers are divided into three trusted databases based on three types of nodes, and a corresponding Bloom filter is designed for each trusted database. In the subsequent verification process, the trustworthiness of the node's real-time identity can be determined simply by verifying whether the node is in the corresponding trusted database.

[0089] The initial authentication process is the registration of the node, which is authenticated through Raft consensus and the corresponding The information is uploaded to the chain and the corresponding certificate and unique hash H(p) are returned. In order to facilitate the efficiency of subsequent authentication, Timely updates are required. Updates are added to the data through Raft consensus, and the latest data information is determined based on the timestamp.

[0090] Subsequent authentication: First, the node's certificate is verified, mainly the CA's digital signature is verified to ensure the authenticity and integrity of the certificate, and thus ensure the credibility of the node's public key and identity information. If the private key of the certificate is leaked, the certificate information is changed, or the certificate owner is no longer trusted, the CA can revoke the digital certificate. The revoked certificate will be included in the certificate revocation list (CRL) or the online certificate status protocol (OCSP) response so that the recipient can verify the status of the certificate during the communication process. Secondly, the real-time behavior of the node is continuously verified to ensure that the node has not "rebelled". Therefore, the present invention designs a credit point incentive mechanism to record each behavior of the node and perform real-time judgment and update settlement. The OT ledger and IT ledger are divided into three trusted databases according to the three types of nodes. In order to reduce the number of consensus times for each verification, the present invention designs a corresponding Bloom filter for each trusted database. In the subsequent verification process, it is only necessary to verify whether the node is in the database to determine whether the node's real-time identity is trustworthy. The process is divided into three steps. The first step is request. The client sends a request to the model. The second step is to pre-judge and map the unique hash value H(p) of each node on the Bloom filter in advance. The present invention assumes that a Bloom filter has an m-bit bit array containing n elements x i ={x1,x2,x3....x n-1 ,x n}, k Bloom filter heavy hash function h i ={h1,h2,h3....h n-1 ,h n}.

[0091] First, initialize the Bloom filter and set the m bits to 0. 1，2,3,,,m =Bit 1，2,3,,,m →0. Secondly, add elements and set n elements to be added x in the set T in advance. 1,,,n Rehash function h using k Bloom filters 1,,,k Hash, h k (x i )={h1(x 1,,,n ),h2(x 1,,,n )....h k-1 (x 1,,,n ),h k (x 1,,,n )}. Each element gets k bits in the Bloom filter and sets them to 1. 1，2,3,,,k =Bit 1，2,3,,,k →1.

[0092] Bloom filter supports element operations such as "query and add", but does not support "modify and delete". Therefore, the larger the number of n, the greater the false positive rate, but it can guarantee a 0 false negative rate. When n / m is too large, it will lead to too high a false positive rate, and in this case, the filter needs to be rebuilt. This invention assumes that the element x i can be mapped to m bits with equal probability. i In an element x i By h i The probability that it is not set to 1 when inserted is ε, Then k h 1,,,k The probability that none of them sets it is β, If n elements are inserted but none of them are set, the probability is α. Then the probability of this bit being set is σ, In the query phase, if the corresponding element x to be queried i If all k bits of the element are set to 1, it can be judged to be in the set. Therefore, the probability of misjudging an element is ρ = (1-σ) k .Depend on When m increases or n decreases, the error rate will decrease. After taking the logarithm, taking the derivative, and finding the maximum value of ρ, we can get When the error rate is the lowest, P(error),

[0093] Finally, perform ICS node authentication and pass the element to be queried x i Hash, that is, {h1(x i ),h2(x i ),,,h k-1 (x i ),h k (x i )}, get k bits, if these k bits are all 1, then the element is in the set T, otherwise not. The design of the Bloom filter only pre-queries the ICS nodes in the model to quickly exclude non-existent nodes and perform fast verification. The third step is matching. When the node is queried, since the Bloom filter has a false alarm rate, it is necessary to traverse and verify the node data after the node is first screened out. The node is specifically based on the path, and information is extracted from the IT ledger and the OT ledger to check the node. To verify, the formula is:

[0094]

[0095] This embodiment also provides a two-layer blockchain-assisted ICS data trusted flow method, an ICS-RBAC zero-trust access control mechanism based on RBAC, and a policy library ST. Device nodes can only access the OT blockchain ledger, interaction nodes can only access the IT blockchain ledger, and workstation nodes can access both the OT blockchain ledger and the IT blockchain ledger. This ensures zero-trust data interaction between the OT blockchain, IT blockchain, and ICS physical devices.

[0096] ICS-RBAC access control mechanism such as Figure 5 shown.

[0097] First, a dynamic identity authentication mechanism is used to quickly register nodes. Based on their registered attributes, they are assigned to corresponding organizations and channels. Next, a policy library (ST) is designed. The OT blockchain consists of device nodes and workstation nodes. Workstation nodes perform data operations on the OT channel. Specifically, device nodes can only access the OT ledger, interaction nodes can only access the IT ledger, and workstation nodes can access both the OT and IT ledgers. The ICS-RBAC mechanism employs a dynamic authorization approach, using credit points to assess node credibility. Real-time credit scores are also used as a basis for authorization. Next, the client sends a request. The OT / IT access control contract authenticates the client and the corresponding object using the dynamic identity authentication mechanism, invokes the access control decision contract, and matches the policy library. Finally, subject authorization is performed, and the ICS policy library is updated. The model includes three types of nodes. Physical device nodes rely on oracles for communication. The following oracle design uses the Modbus TCP protocol as an example, as shown in Algorithm 1.

[0098]

[0099]

[0100] In one implementation, the OT blockchain access control process is divided into seven steps:

[0101] (1) User Send a transaction Tx i For OT Access Control Contract (OT-ACSC), the transaction contains the certificate CA i , Object ID i , operation content OP, real-time environmental factors EV i (IP, real-time time, etc.) and real-time credit score Tr i , hash the message using SHA256 and use sk p Tx i Encrypt and generate digital signature Sig,

[0102] (2) OT-ACSC Use dynamic identity authentication mechanism for verification, including verification and checks whether it is in the trusted database.

[0103] (3) If passed, the dynamic identity authentication mechanism verifies the object Identity, including verification and checks whether it is in the trusted database.

[0104] (4) Verify that the policy library ST is matched by calling the OT access control decision contract (OT-ADSC).

[0105] (5) If the permissions are met, authorization is performed and the matching result Match is returned to OT-ACSC.

[0106] (6) OT-ACSC will Tx i use Public key pk p Perform RSA encryption and send Sig to s i Node is sent to s i On-chain mapping node, Receive Tx i And after Sig, it will be used The public key pk p Decrypt Sig to obtain Tx i Then, Hash the original message using the same hash function SHA256 and compare the resulting hash value with the decrypted hash value. If the two hash values ​​match, the digital signature Sig is valid and Tx i Complete and from the sender. Then use The private key is decrypted and the Oracle-Modbus TCP contract is called to issue data instructions to the on-site equipment.

[0107] (7) Data Generate digital signature Sig (physical device node, first return to the mapping node on the chain, then generate Sig), OT risk prevention and control contract (OT-RPSC) To ensure the secondary verification. as well as To determine the validity of credit points, we design a time threshold Time and make a threshold determination on the time interval. The determination process is as follows: Will Use RSA encryption and return the result with Sig Verify and decrypt, record on blockchain and update credit points.

[0108] The pseudo code design of OT-ACSC is shown in Algorithm 2, the pseudo code of OT-ADSC is shown in Algorithm 3, and the pseudo code of OT-RPSC is shown in Algorithm 4.

[0109]

[0110]

[0111]

[0112]

[0113]

[0114]

[0115] In one implementation, the IT chain access control process is divided into seven steps:

[0116] (1) User Send a transaction Tx i For IT Access Control Contract (IT-ACSC), the transaction includes the certificate CA i , Object ID i , query content RP and real-time credit score Tr i , hash the message using SHA256 and use sk p Tx i Encrypt and generate a digital signature Sig.

[0117] (2) IT-ACSC Use dynamic identity authentication mechanism for verification, including verification and checks whether it is in the trusted database.

[0118] (3) If passed, the dynamic identity authentication mechanism verifies the object Identity, including verification and checks whether it is in the trusted database.

[0119] (4) Verify that the policy library ST is matched by calling the OT access control decision contract (IT-ADSC).

[0120] (5) If the permissions are met, authorization is performed and the matching result (Match) is returned to IT-ACSC.

[0121] (6) IT-ACSC will Txi use Public key pk p Perform RSA encryption and send to Sig Receive Tx i And after Sig, it will be used The public key pk p Decrypt Sig to obtain Tx i Then, Hash the original message using the same hash function SHA256 and compare the resulting hash value with the decrypted hash value. If the two hash values ​​match, the digital signature Sig is valid and Tx i Complete and from the sender. Then use Private key for decryption.

[0122] (7) Data Generate digital signature Sig, IT risk prevention and control contract (IT-RPSC) To ensure as well as To determine the validity of credit points, we need to design a time threshold and make a threshold judgment on the time interval. Use RSA encryption and return the result with Sig Verify and decrypt, and update blockchain records and credit points.

[0123] Since IT-ACSC and OT-ACSC, as well as IT-RPSC and OT-RPSC, differ only in node properties, pseudocode is not provided. IT-ADSC is shown in Algorithm 5.

[0124]

[0125]

[0126] In one implementation, OT&IT cross-chain access control, the workstation node can access the OT chain and IT chain ledgers. Therefore, the node is a model relay node and serves as an audit node for cross-chain data. The data cross-chain method is as follows: Figure 6 As shown, the specific process is divided into ten steps:

[0127] (1) Request verification: Requester Send a transaction Tx i To IT-ACSC or OT-ACSC. i Hash it using the SHA256 hash function and use sk p Tx iEncrypt and generate a digital signature Sig.

[0128] (2) IT-ACSC or OT-ACSC Use dynamic authentication mechanism for verification.

[0129] (3) If passed, use Raft consensus to select g i Node (leader), and use dynamic identity authentication mechanism to verify the node, and use credit points to verify g i Nodes are incentivized.

[0130] (4) Verify that the strategy library ST is matched by calling OT-ADSC or IT-ADSC.

[0131] (5) If the permissions are met, authorization is performed and the matching result is returned to the OT-ADSC or IT-ACSC.

[0132] (6) IT-ACSC or OT-ACSC will Tx i use Public key pk p Perform RSA encryption and send to Sig Receive Tx i And after Sig, it will be used The public key pk p Decrypt Sig to obtain Tx i Then, Hash the original message using the same hash function SHA256 and compare the resulting hash value with the decrypted hash value. If the two hash values ​​match, the digital signature Sig is valid and Tx i Complete and from the sender. Then use Private key for decryption.

[0133] (7) Data extraction: Transfer OT or IT chain requests across chains and i Broadcast, the requested node The nodes on the chain use the Raft consensus mechanism to reach consensus. After the consensus is reached, Encrypt the data using the RSA encryption algorithm and send it to the interactive node g i .

[0134] (8) Data verification: g i The data is verified using a dynamic identity authentication mechanism, including verifying the authenticity of the data (path, identity verification) and whether it has been tampered with (signature verification).

[0135] (9) Data upload: gi Package the data, data provider nodes, etc. into a transaction And upload data across chains.

[0136] (10)OT-RPSC or IT-RPSC for g i To ensure the validity of the credit points of participating nodes, a time threshold is designed and a threshold is determined for the time interval. Encrypt using RSA and return the result to Sig Verify and decrypt, and update blockchain records and credit points.

[0137] This embodiment also provides a trusted ICS data transfer method based on a two-layer blockchain, which uses an active defense mechanism combining a heartbeat mechanism with blockchain intelligence to detect dishonest nodes in real time.

[0138] This embodiment combines blockchain ledger data with the heartbeat mechanism to verify ICS system downtime, failures, and counterfeit nodes and devices for active defense. Figure 7 As shown. Combining this heartbeat test with normal operations, if the heartbeat test is correct, it can ensure that the node does not perform malicious operations (forged instruction requests, forged return data) during normal data access and sharing. The specific process of the active defense mechanism based on the heartbeat test principle is divided into four steps:

[0139] (1) Set the heartbeat test cycle time T h , and not greater than the T h In the process, a random challenge is sent to the node. The challenge is designed as follows: randomly select the historical test timestamp, set the challenge feedback time threshold T t .

[0140] (2) According to the historical timestamp, query the corresponding blockchain ledger and randomly obtain data interaction request records.

[0141] (3) Call the data interaction record of both parties and compare it with the blockchain account data. If the data is in the specified T t If there is no reply within T, the node is judged as a problem node and artificial testing is carried out to distinguish between downtime, failure and forgery. t If the node responds and compares the results within 10 seconds, the node is considered a safe node. Finally, the credit values ​​of different types of nodes are updated and marked.

[0142] The present invention is further described below through specific experiments.

[0143] First, the roles of the industrial control system were extracted, and the device nodes, workstation nodes, and interaction nodes were determined, covering the participants of the industrial control system. The double-layer blockchain architecture of OT chain and IT chain was designed (see Figure 2 ), deploy nodes of different roles on different blockchains.

[0144] The full-chain broadcasting of certificate information for device nodes, workstation nodes, and interactive nodes, along with off-chain storage of operations, logs, and other data, meets the high privacy requirements of industrial control system (OT) data flow and reduces attacks on industrial control systems from external network environments. The dynamic authentication process supports the sustainability of verification within the ICS-RBAC zero-trust access control strategy. By designing a Bloom filter and a trusted database, the number of consensuses required during each authentication phase is reduced, thereby reducing the time spent on user identity traversal. The ICS-RBAC zero-trust access control mechanism is divided into OT, IT, and OT / IT access control. Through RSA encryption algorithms, digital signatures, smart contracts, and a "one-step, one-verification" design, it ensures zero-trust data access based on "never trust, continuous verification, centralized policy management, dynamic, and minimized authorization" during data sharing and access by different roles in the industrial control system. This solution is both reliable and feasible.

[0145] By combining blockchain ledger data with the heartbeat mechanism, ICS system downtime, failures, and forged nodes and devices can be verified, enabling active defense of the physical equipment of the industrial control system and nodes on the chain.

[0146] The dynamic identity authentication mechanism's efficiency was verified and compared with data queries performed without a Bloom filter. Because the Bloom filter serves as a pre-screening mechanism, the false positive rate was set to 0.01 in this experiment. A total of 100,000 data sets were simulated. The number of binary bits and memory required for different data volumes are shown in Table 1.

[0147] Table 1 Parameter settings

[0148]

[0149]

[0150] Figure 8 The following graph compares the time it takes to filter a node that is not in the trusted database using a Bloom filter with the time it takes to filter a node that is not in the trusted database using a Bloom filter, with the time it takes to filter a node that is not in the trusted database using a Bloom filter, showing that the design of the present invention can quickly filter out dishonest nodes (nodes that are not in the trusted database). This is because the query operation only requires simple bit operations in the bit array, and the query time complexity is O(1) regardless of the data volume.

[0151] Figure 9 The box plot of time consumption when the present invention uses a Bloom filter to randomly query data 100 times under different data volumes is shown. It can be seen that with the increase in data volume, the time consumption of the identity authentication mechanism designed in this article does not increase significantly, and the average query time consumption is 1 microsecond, which is an acceptable value compared to the efficiency improvement brought about by the screening of dishonest nodes. It can meet the frequent data interactions of industrial control systems and the frequent role verification requests required by the designed "one transmission and one verification" mechanism.

[0152] ICS-RBAC access control mechanism verification,the simulation environment configuration is shown in Table 2.

[0153] Table 2 Simulation environment configuration

[0154]

[0155]

[0156] This experiment demonstrates the data distribution process of simulated workstation nodes to device nodes. First, Figure 10 (a) is the chain code call function, which is used to call the OT-ACSC contract. Secondly, this experiment generates three ECDSA certificates for the device node, workstation node, and interactive node, and uses the x509.CreateCertificate method to generate the corresponding self-signed certificates, and uses the ecdsa.GenerateKey method to generate the elliptic curve (P-384) private key of the relevant node. Then, this experiment simulates RSA encryption and generates an RSA certificate. The certificate template is as follows: Figure 10 (b) The certificates (public keys) and private keys of the device nodes, workstation nodes, and interactive nodes are as follows: Figure 11 As shown in (a), the RSA private key is Figure 11 As shown in (b), the certificate (public key) is as follows Figure 11 (c) shown.

[0157] This experiment uses the access to the device node as an example to demonstrate the chain code. First, the workstation node C accesses the device node s. i After signing, the contract verifies the identities of C and the device node. If verification is successful, the corresponding access control policy is matched, and C obtains the corresponding permissions. The contract then parses and verifies the s node certificate and extracts the s node public key. C uses the device node public key to perform RSA encryption and sends the data request. The device node s uses its own private key to decrypt the data and verify the correctness of the message. If it is correct, it will call Oracle-Modbus TCP to issue the instruction. Figure 12This shows how the contract parses and verifies the certificate of device node s and extracts the public key. Figure 13 The process of device node s using private key to decrypt data is shown. The device node s uses the same method to encrypt the request data and return it to the workstation node. The present invention has tested it, and the test results are as follows Figure 14 shown.

[0158] This experiment conducted use case tests on the designed model functions, including node registration function, authentication function, permission matching function and active defense function. After testing, the model can provide reliable protection for the flow of data in the industrial control system, achieve deep isolation between OT and IT, and zero-trust access control. The test table is shown in Figure 3.

[0159] Table 3: Partial functional test table

[0160]

[0161] It should be understood that the embodiments described above are only some of the embodiments of the present invention, rather than all of the embodiments. In addition, the technical features of the various embodiments or individual embodiments provided by the present invention may be arbitrarily combined with each other to form a feasible technical solution. Such combination is not restricted by the order of steps and / or structural composition mode, but must be based on the ability of ordinary technicians in this field to implement it. When the combination of technical solutions is mutually inconsistent or cannot be implemented, it should be deemed that such combination of technical solutions does not exist and is not within the scope of protection claimed by the present invention.

[0162] It should be understood that the above description of the preferred embodiment is relatively detailed and cannot be regarded as limiting the scope of protection of the patent of the present invention. Under the guidance of the present invention, ordinary technicians in this field can also make substitutions or modifications without departing from the scope of protection of the claims of the present invention, which all fall within the scope of protection of the present invention. The scope of protection requested by the present invention shall be based on the attached claims.

Claims

1. A two-layer blockchain-assisted ICS data trusted circulation system, characterized by: The system includes a manufacturing execution layer, a process monitoring layer, a control network layer, and a field control layer. The system uses two blockchain layers: the OT blockchain and the IT blockchain, for trusted data transfer. The OT blockchain ledger represents the internal data flow of the ICS, while the IT blockchain ledger represents the data flow of information exchange between the ICS and the outside world. The ICS node includes device nodes s i , workstation node g i and interaction node j i ;Device nodes i For the chain mapping of field control devices, the workstation node g i Including engineer workstation, operation station and operation and maintenance station, interactive node i is an external workshop node; the equipment node s i , register on the OT blockchain, return the corresponding certificate and unique hash H(p), and back up the certificate information in the IT blockchain consensus; the interactive node j i , register on the IT blockchain, return the corresponding certificate and unique hash H(p), and back up the certificate information in the OT blockchain consensus; the workstation node g i , which belongs to the relay node of OT blockchain and IT blockchain. After being on the OT blockchain, it is registered and on the IT blockchain, and returns the corresponding certificate and unique hash H(p).

2. The ICS data trusted transfer system based on a two-layer blockchain as claimed in claim 1 is characterized by: Device nodes i When registering on the blockchain, the user Client first sends a registration request to the OT blockchain and sends relevant registration information OT blockchain nodes verify and vote through Raft consensus, and send the consensus results to physical devices for verification and matching; the physical devices return the verification result information to the OT blockchain, and Match and send the final consensus result to the certification center CA; the certification center CA will check the device node s i Generate a unique certificate, sign it, broadcast it, issue it to the physical device node and OT blockchain, and return the result to the user client; finally, broadcast the result of this registration request to the IT blockchain, and the IT blockchain will perform a distributed backup of the information through a round of broadcasting. The device node s i Register on the chain.

3. The ICS data trusted transfer system based on a double-layer blockchain as claimed in claim 1 is characterized by: Interaction node j i When registering on the blockchain, the user Client first sends a registration request to the IT blockchain and sends relevant registration information The nodes in the IT blockchain use Raft consensus to send the consensus results to the certification center CA; the certification center CA signs and generates a unique certificate, issues the certificate, and broadcasts the consensus results to the OT blockchain nodes; the OT blockchain is broadcast to all nodes for backup after a round of broadcasting, and the results are returned to the user Client, the interaction node j i Register on the chain.

4. The ICS data trusted transfer system based on a two-layer blockchain as claimed in claim 1 is characterized by: Workstation Node g i When registering on the blockchain, the user Client first sends a registration request to the OT blockchain and sends relevant registration information OT blockchain nodes use Raft to vote and send the OT blockchain consensus results to R OT and registration information Send it to the IT blockchain, and the IT blockchain nodes will vote and reach consensus through Raft, and the OT blockchain consensus result R OT And the IT blockchain consensus result R IT Send to the certification center CA; the certification center CA signs and generates a unique certificate, which is issued to the user Client, OT blockchain and IT blockchain, and workstation node g i Register on the chain.

5. A method for trusted transfer of ICS data based on a two-layer blockchain, applied to the system according to any one of claims 1 to 4; characterized in that: Through the Bloom filter and the identity-assisted authentication mechanism of the trusted database, dishonest nodes can be quickly checked; Through a credit point incentive mechanism, every node behavior is recorded, and real-time judgment, update, and settlement are performed. The OT blockchain ledger and IT blockchain ledger are divided into three trusted databases according to the three types of nodes, and a corresponding Bloom filter is designed for each trusted database. In the subsequent verification process, it is only necessary to verify whether the node is in the corresponding trusted database to determine whether the node's real-time identity is trustworthy. The Bloom filter has an m-bit bit array containing n elements x i The set T of k Bloom filter heavy hash functions h k ; First, initialize and set the m bits of the Bloom filter to 0; then add elements and set the n elements to be added x in the set T 1,,,n Rehash function h using k Bloom filters 1,,,k Hash, each element gets k bits in the Bloom filter and sets them to 1; when performing node authentication, the element to be queried x i Hash, that is, {h1(x i ),h2(x i ),,,h k-1 (x i ),h k (x i )}, get k bits. If these k bits are all 1, then the element is in the set T, otherwise it is not. After the node is first screened out, the node data is traversed and verified, and the node is specifically based on the path, information is extracted from the IT blockchain ledger and the OT blockchain ledger, and the node registration information is verified.

6. A method for trusted transfer of ICS data based on a two-layer blockchain, applied to the system according to any one of claims 1 to 4; characterized in that: Based on the ICS-RBAC zero-trust access control mechanism of RBAC, a policy library ST is created. Device nodes can only access the OT blockchain ledger, interaction nodes can only access the IT blockchain ledger, and workstation nodes can access both the OT blockchain ledger and the IT blockchain ledger; thus, zero-trust data interaction between the OT blockchain, IT blockchain, and ICS physical devices is ensured.

7. The method for trusted transfer of ICS data based on a double-layer blockchain as claimed in claim 6 is characterized by: The specific implementation of OT blockchain access control includes the following sub-steps: (1) The subject sends a transaction Tx i To the OT access control contract OT-ACSC, the transaction contains the certificate CA i , Object ID i , operation content OP, real-time environmental factors EV i And real-time credit score Tr i , Tx i Hash it with SHA256 and use your own private key sk p Tx i Encrypt and generate digital signature Sig; (2) OT-ACSC uses a dynamic identity authentication mechanism to verify the subject, including verifying the subject's certificate and determining whether it is in the trusted database; (3) If the verification is successful, the dynamic identity authentication mechanism is called to verify the identity of the object, including verifying the object's certificate and determining whether it is in the trusted database; (4) If the verification is successful, the OT access control decision contract OT-ADSC is called to match the policy library ST; (5) If the permissions are met, authorization is performed and the matching result is returned to OT-ACSC; (6) OT-ACSC will Tx i Use the object public key pk p Perform RSA encryption and Sig to send to the object, the device node sends it to the mapping node on the OT blockchain, and the object receives Tx i After Sig, use the object public key pk p Decrypt Sig to obtain Tx i The hash value of The object then hashes the original message using the same hash function SHA256 and compares the generated hash value with the decrypted hash value; if the two hash values ​​match, the digital signature Sig is valid and Tx i Complete and from the sender; then use the object private key to decrypt and obtain And call the Oracle-Modbus TCP contract to issue data instructions to the on-site equipment; (7) Object to Data Generate digital signature Sig, OT risk prevention and control contract OT-RPSC performs secondary verification on the object; in order to ensure the validity of the subject and object credit points, the time threshold Time is designed, and the time interval threshold is determined. Use RSA encryption and return it to the subject together with Sig and the result. The subject verifies and decrypts it, and then records it on the blockchain and updates the credit score.

8. The method for trusted transfer of ICS data based on a double-layer blockchain as claimed in claim 6 is characterized by: The specific implementation of IT blockchain access control includes the following sub-steps: (1) User Send a transaction Tx i To the IT access control contract IT-ACSC, the transaction includes the certificate CA i , Object ID i , query content RP and real-time credit score Tr i , Tx i Hash it using SHA256 and use Your own private key sk p Tx i Encrypt and generate digital signature Sig; (2) IT-ACSC Use dynamic identity authentication mechanism for verification, including verification and check whether the certificate is in the trusted database; (3) If the verification is successful, the dynamic identity authentication mechanism is called to verify the object Identity, including verification and check whether the certificate is in the trusted database; (4) If the verification is successful, the IT access control decision contract IT-ADSC is called to match the policy library ST; (5) If the permissions are met, authorization is performed and the matching result is returned to IT-ACSC; (6) IT-ACSC will Tx i use Public key pk p Perform RSA encryption and send to Sig Receive Tx i And after Sig, use The public key pk p Decrypt Sig to obtain Tx i The hash value of ; then, Hash the original message using the same hash function SHA256 and compare the generated hash value with the decrypted hash value; if the two hash values ​​match, the digital signature Sig is valid and Tx i Complete and from the sender; and then use The private key is used to decrypt and obtain the data (7) Data Generate digital signature Sig, IT risk prevention and control contract IT-RPSC Perform secondary verification to ensure as well as To determine the validity of credit points, we need to design a time threshold, and make a threshold judgment on the time interval. Use RSA encryption and return the result with Sig Verify and decrypt, and update blockchain records and credit points.

9. The method for trusted transfer of ICS data based on a double-layer blockchain as claimed in claim 6, characterized in that: The specific implementation of OT&IT cross-chain access control includes the following sub-steps: (1) Request verification: The requester sends a transaction Tx i Give IT access control contract IT-ACSC or OT access control contract OT-ACSC; i Hash it using the SHA256 hash function and use the public key sk p Tx i Encrypt and generate digital signature Sig; (2) IT-ACSC or OT-ACSC verifies the requester using a dynamic identity authentication mechanism; (3) If the verification is passed, the Raft consensus is used to select g i Node, and use dynamic identity authentication mechanism to verify the node, use credit points to verify g i Nodes are incentivized; (4) If the verification is successful, the OT access control decision contract OT-ADSC or the IT access control decision contract IT-ADSC is called to match the policy library ST; (5) If the permissions are met, authorization is performed and the matching result is returned to the OT-ADSC or IT-ACSC; (6) IT-ACSC or OT-ACSC will Tx i Use g i Node public key pk p Perform RSA encryption and send it to the requester with Sig, g i Node receives Tx i And after Sig, the requester's public key pk p Decrypt Sig to obtain Tx i The hash value of g i The node hashes the original message using the same hash function SHA256 and compares the generated hash value with the decrypted hash value; if the two hash values ​​match, the digital signature Sig is valid and Tx i Complete and from the sender; then use the g i Node private key is used for decryption; (7) Data extraction: g i The node transfers the OT blockchain or IT blockchain request across chains and i The nodes on the chain where the requested node is located use the Raft consensus mechanism to reach a consensus. After the consensus is reached, the data is encrypted using the RSA encryption algorithm and sent to the interactive node g. i ; (8) Data verification: g i The data is verified using a dynamic identity authentication mechanism, including verifying the authenticity of the data and whether it has been tampered with; (9) Data upload: g i Package the data and the data providing node into a transaction And upload data across chains; (10) OT risk prevention and control contract OT-RPSC or IT risk prevention and control contract IT-RPSC i To ensure the validity of the credit points of participating nodes, a time threshold is designed and a threshold is determined for the time interval. Use RSA encryption and return it to the requester together with Sig and the result. The requester verifies and decrypts it, and then records it on the blockchain and updates the credit score.

10. A method for trusted transfer of ICS data based on a two-layer blockchain, applied to the system according to any one of claims 1 to 4; characterized in that: An active defense mechanism based on the combination of heartbeat mechanism and blockchain intelligence to detect dishonest nodes in real time; The specific implementation includes the following sub-steps: (1) Set the heartbeat test cycle time T h , and not greater than the T h In the process, a random challenge is sent to the node. The challenge is designed as follows: randomly select the historical test timestamp, set the challenge feedback time threshold T t ; (2) According to the historical timestamp, query the corresponding blockchain ledger and randomly obtain data interaction request records; (3) Call the data interaction record of both parties and compare it with the blockchain account data. If the data is in the specified T t If there is no reply within T, the node is judged as a problem node and artificial testing is carried out to distinguish between downtime, failure and forgery. t If the node responds and compares the results within 1 second, the node is a safe node; (4) Update the credit values ​​of different types of nodes and mark them.

Images