Industrial cross-domain trusted network connection method based on multi-layer alliance chain

Abstract

The application discloses an industrial cross-domain trusted network connection method based on a multi-layer alliance chain, an alliance chain model CertChain, a five-element trusted cross-domain connection architecture and a cross-domain trusted network connection protocol TCA-MLB based on the multi-layer alliance chain are designed based on the architecture. The alliance chain CertChain binds the network access layer and the integrity evaluation layer of the TCA to resist the man-in-the-middle attack and decentralize the trusted third party. The five-element trusted cross-domain connection architecture expands the trusted connection architecture TCA horizontally, so that the TCA is applicable to cross-domain authentication, and the security features such as decentralization and tamper resistance of the alliance chain are fully integrated. The TCA-MLB protocol performs user identity information authentication, platform identity information authentication and platform integrity measurement value checking when the device performs intradomain access or cross-domain access, can resist various security problems, and ensures the reliability and safety of the device under the interconnection of the multiple control domains of the industrial control network.

Description

Technical Field

[0001] This invention relates to the field of industrial control network technology, and in particular to a method for cross-domain trusted network connection of industrial equipment based on a multi-layer consortium blockchain. Background Technology

[0002] With the frequent mention of concepts such as "Industry 4.0" and "two-network convergence" in recent years, industrial control networks rely on various communication technologies to improve industrial production efficiency and reduce management costs through information sharing, interconnection, value exchange, and collaborative control among multiple trust domains. However, security issues have also become prominent. Currently, industrial control networks mainly have the following four security problems: (1) The cross-domain authentication mechanism of traditional ICN is insufficient. The security of ICN devices relies on the exclusivity and natural isolation of devices to ensure information security, and lacks an effective cross-domain authentication mechanism. If the cross-domain authentication mechanism is insufficient, attackers may obtain sensitive information or disrupt the production process by infiltrating across control domains; or when making cross-domain request operations, if there is no cross-domain authentication mechanism, the request operation may be rejected, which will lead to delays in the production process; (2) The current mainstream solution is to achieve secure cross-domain access by issuing trusted tickets / certificates by third parties or by centralized authentication. These centralized authentication methods are difficult to adapt to the massive number of ICN devices and the increasingly complex network environment. Moreover, centralized trusted third parties are potential attack targets and are prone to security problems; (3) Industrial control collaboration scenarios are not suitable for a single root of trust. Each trust domain has its own set of secure access policies, and not all industrial control devices have the need for cross-domain access; (4) The existing cross-domain authentication mechanism only authenticates the identity of the user accessing the device, lacks platform identity authentication and platform integrity verification of the device, lacks comprehensive verification of other aspects of the device, and cannot determine whether the device has been tampered with or attacked. At the same time, the existing cross-domain identity authentication mechanism still faces security threats such as man-in-the-middle attacks and the problem of unilateral control. Cross-domain authentication is of great security significance as a prerequisite for secure collaboration between control domains in industrial control networks and the foundation for secure data access.

[0003] Based on the above analysis, collaboration between industrial control networks is becoming increasingly frequent, leading to more complex security threats. Simply porting traditional cross-domain authentication protocols to industrial control networks is not suitable. Addressing issues such as single points of failure in trusted third parties, unilateral network control, and defense against various malicious attacks, a secure and reliable cross-domain authentication scheme is needed to ensure the reliability and security of equipment while maintaining interconnectivity across multiple control domains within the industrial control network. Therefore, this invention proposes TCA-MLB, a multi-layered consortium blockchain-based industrial cross-domain trusted network connection method, to guarantee secure and reliable cross-domain access for industrial equipment. Summary of the Invention

[0004] To address issues such as single point of failure in trusted third parties, unilateral network control, and defense against various malicious attacks, this invention proposes a method for cross-domain trusted network connections in industrial applications based on a multi-layer consortium blockchain. By applying the Trusted Connection Architecture (TCA) to the cross-domain access domain of industrial control networks and decentralizing the Policy Manager (PM) based on consortium blockchain technology, this method achieves bidirectional authentication and platform integrity metric verification between industrial control devices, ensuring that only authorized and legitimate industrial devices can perform cross-domain access.

[0005] This invention first designs a CertChain structure to store user identity information and platform information, ensuring secure storage of authentication information and providing security for cross-domain authentication protocols. It also defends against man-in-the-middle attacks by binding user certificates and platform certificates. Then, by horizontally scaling the Trusted Connection Architecture (TCA), a five-element trusted cross-domain connection architecture suitable for cross-domain authentication is proposed, integrating the decentralized and tamper-proof security features of consortium blockchains. Finally, device registration, intra-domain authentication, and cross-domain authentication are performed. The registration phase mainly packages user identity information, platform information, and other registration information for storage on the consortium blockchain, which is the foundation for secure communication. The intra-domain authentication phase verifies local industrial equipment information, which is the basis for cross-domain authentication. Cross-domain authentication is crucial for ensuring trusted cross-domain access of industrial equipment to other trusted domains.

[0006] Registration Phase. In the industrial control network, a server with abundant storage resources acts as a trusted third-party entity for cross-domain authentication, namely the Distributed Policy Manager (DPM), responding to identity registration requests from devices within the domain and providing consortium blockchain services. During the registration phase, the DPM is responsible for receiving cross-domain authentication registration requests from industrial ICS devices and gateways (GWs) within the domain, obtaining user identity information, corresponding keys, platform identity information, and platform integrity metrics, and generating corresponding certificates. Finally, it issues user identity certificates (Certificates) to the ICS devices and gateways (GWs) in the network. user And broadcasting to the entire consortium blockchain network, through verification nodes with accounting rights, the user's identity certificate Cert... user and platform certificate Cert device It is packaged into a new block proposal, then verified and approved by the entire network, and the registration is completed.

[0007] Intra-domain authentication. This stage is the process of industrial equipment accessing the local trusted network. Trusting ICS devices in domain A, i.e., the accessor AR... A To the same domain gateway GW, i.e., access controller AC A Send network access request, AC A Upon receiving the request, a two-way peer-to-peer trusted authentication is completed with the Distributed Policy Manager (DPM) under the service provided by the Blockchain LBC, and the DPM then performs the authentication based on the AR. AThe access requirements (intra-domain authentication / cross-domain authentication) determine whether to enable AR. A The user's identity certificate and platform certificate are broadcast and uploaded to the global chain PBC. This stage ensures that when any device accesses the local trusted domain, the user's identity and platform are trusted, which is a necessary prerequisite for cross-domain authentication.

[0008] Cross-domain authentication. When devices in trust domain A exchange information with devices in trust domain B, cross-domain authentication is required. During the cross-domain authentication phase, some devices in trust domain A perform user authentication and platform authentication with devices in trust domain B. In this process, the Distributed Policy Manager (DPM) provides services under the global chain PBC, and AR... A With AC B The system employs a two-way peer-to-peer trusted authentication mechanism. This phase ensures the trustworthiness of both user identities and platforms when any device accesses a non-local trusted domain across domains. Adding random numbers during message interaction prevents replay attacks. During two-way user identity authentication and platform authentication, DPM, as a trusted third party, centrally manages AR and AC, preventing collusion attacks between devices inside and outside the trusted network. Encryption technology is used to encrypt authentication information before transmission, preventing unauthorized third parties from obtaining the original data and ensuring data confidentiality. During protocol interaction, the secret random number for negotiating the communication key is randomly generated each time, independent of the random numbers from previous interactions, ensuring forward security. A decentralized trusted third party, the distributed policy manager, is built using consortium blockchain technology. This manager is responsible for verifying user identity and platform information to ensure the legitimacy of the user's identity and reduce the risk of single points of failure in the trusted third party. The CertChain contains two fields that bind user identity and platform information, thus resisting man-in-the-middle attacks caused by TCA. Immutability is a security feature of the CertChain and the foundation for building distributed trust.

[0009] This invention proposes a cross-domain trusted network connection method, TCA-MLB, based on a multi-layer consortium blockchain. This cross-domain authentication method features forward security and immutability, ensuring the confidentiality and trustworthiness of device and platform authentication information. It can resist collusion attacks, man-in-the-middle attacks, and replay attacks, achieving bidirectional identity authentication between cross-domain devices, platform identity authentication, and platform integrity metric verification, while reducing the risk of single points of failure from trusted third parties. Furthermore, it reduces communication overhead during the authentication process and improves execution efficiency. Attached Figure Description

[0010] Figure 1 This is a schematic diagram of the overall architecture of the cross-certification system of the present invention.

[0011] Figure 2This is a schematic diagram of the CertChain data structure of the present invention.

[0012] Figure 3 This is a schematic diagram of the five-element trusted cross-domain connection architecture of the present invention.

[0013] Figure 4 This is a schematic diagram illustrating the specific process of the domain authentication method of this invention.

[0014] Figure 5 This is a schematic diagram illustrating the specific process of the cross-domain authentication method of the present invention. Detailed Implementation

[0015] The present invention will now be described in detail with reference to the specific embodiments shown in the accompanying drawings.

[0016] Figure 1 This is a schematic diagram of the overall structure of the TCA-MLB industrial cross-domain trusted network connection method based on a multi-layer consortium blockchain, as shown in the figure. Figure 1 As shown.

[0017] In the trusted network connection architecture of a multi-layered consortium blockchain, each trust domain contains entities such as ICS devices, gateways (GW), distributed policy managers (DPM), blockchains (LBC), and a global blockchain (PBC) composed of DPMs from multiple domains. In this architecture, the ICS device is the entity participating in cross-domain information exchange and initiates cross-domain authentication requests as an access requester (AR), possessing both user identity certificates and platform authentication certificates. The GW acts as the access controller (AC) entity in this architecture and also possesses multiple unique user identity IDs. User and a unique device identification ID Device Its responsibilities include responding to and controlling access to the trusted network by ICS devices both within and outside the domain, and executing access control decisions by the DPM. In this scheme, the DPM acts as a trusted third-party entity for cross-domain authentication, and its functions include responding to identity registration requests from devices within the domain, acting as a trusted third party, and providing consortium blockchain services. The consortium blockchain network provides decentralized identity information storage and cross-domain authentication services, comprising two layers: a local blockchain (LBC) within the domain and a cross-domain blockchain (PBC). The local blockchain (LBC) is primarily responsible for providing intra-domain authentication services when devices within the domain access the trusted network; the cross-domain blockchain (PBC) is primarily responsible for providing cross-domain authentication services when devices need to access the network across domains.

[0018] Figure 2 This invention is based on the data structure CertChain designed for consortium blockchains, such as... Figure 2 As shown.

[0019] In industrial control networks, all nodes in a consortium blockchain maintain and store a common ledger, the CertChain. This ledger is maintained by the accounting nodes through smart contracts and consensus algorithms, and stores two types of certificate transactions. The CertChain consists of a block header and a block body. The block header includes the previous block hash, block number, version, timestamp, and hash root. The block body comprises multiple transactions, each representing a consortium blockchain certificate. These certificates are of two types: user identity certificates and platform certificates. These two types of certificates are used at different stages. User identity certificates include a certificate UID, holder ID, holder public key, and a platform certificate ID set. The platform certificate ID set is the set of certificate IDs of the platform certificates bound to this user identity certificate. Platform certificate transactions include a certificate DID, holder ID, integrity metric IM, and a user identity certificate ID set. The integrity metric IM is used to measure the integrity, reliability, and trustworthiness of a system or hardware / software during operation.

[0020] Figure 3 This invention is a horizontal extension of the Trusted Connectivity Architecture (TCA), proposing a trusted cross-domain network connection architecture based on a multi-layer consortium blockchain, namely the five-element trusted cross-domain connection architecture. Figure 3 As shown.

[0021] The five-element trusted cross-domain connection architecture comprises four functional modules: user identity authentication, platform authentication, integrity measurement, and blockchain service, as well as five entities, including the access requester AR of trusted domain A. A Access Controller AC A AR, the access requester of trusted domain B B Access Controller AC B The system also includes a Distributed Policy Manager (DPM). The User Authentication module, managed by the DPM, authenticates the access requester (AR) or access controller (AC) and handles network communication and access control between components. The Platform Authentication module, also managed by the DPM, authenticates the access requester (AR) and verifies platform integrity. The Integrity Measurement module collects and verifies the integrity values ​​of each platform component and sends the results to the AC. The Blockchain Service module primarily stores user identity information, platform identity information, and platform integrity measurements, and provides authentication information to the Distributed Policy Manager, which acts as a trusted third party.

[0022] Figure 4 This is a schematic diagram illustrating the specific process of the domain authentication method of this invention, as shown below. Figure 4 As shown.

[0023] Step 41, AR A To AC A Initiate an access authentication request and generate a challenge nonce.

[0024] AR A →AC A :nonce(1)

[0025] Step 42, AC A AC response A Access authentication request, and from DPM public key group KG DPM Choose a DPM public key K DPM1 Send to AC A .

[0026] AC A →AR A :K DPM1 (2)

[0027] Step 43, AR A Received AC A After receiving the data packet, extract the public key K. DPM1 Check if it has its own DPM public key group KG DPM If it exists, then generate a random number S. ARDPM and N AR and using DPM public key K DPM1 Encrypted User Identity Certificate Send it to AC A If it does not exist, the connection will be closed.

[0028]

[0029] Step 44, AC A Received AR A After receiving the data packet, check for replay attack prevention using random numbers and generate a random number S. ACDPM and N AC With user identity certificate After encryption, send them together to DPM.

[0030]

[0031] Step 45, DPM receives data from AC A After the data packet, check for random number defense against replay attacks using the private key. Decrypt and obtain S ACDPM and S ACDPM And on the consortium blockchain according to Query and obtain the corresponding user identity certificate and It also verifies the validity of the certificate. If the certificate verification is successful, it generates the user identity certificate verification result. and And extract the AR from the certificate respectively A Public Key and AC A Public key K AC A Generate random number S DPMAR S DPMAC N1 and N2, will S DPMAR and S ARDPM DPM and AR are generated using a key generation algorithm. A Communication key K DPMAR ; will S DPMAC and S ACDPM DPM and AC are generated using a key generation algorithm. A Communication key K DPMAC The random number, user authentication certificate verification result, and public key are encrypted and returned to the AC. A .

[0032]

[0033]

[0034] Step 46, AC A After receiving the data packet from DPM, use the private key. Decrypt the data packet and extract the random number S. DPMAC AR A Verification result of user identity certificate and public key Where the random number S ACDPM With random number S DPMAC Generate a communication key K with DPM based on the key generation algorithm. DPMAR If the verification is successful, generate a random number S. ACAR And encrypt it with the content for AR A If verification fails, disconnect AC. A with AR A The connection.

[0035]

[0036] Step 47, AR A Received AC A After receiving the data packet, check for random number defenses against replay attacks using the private key. Decrypt the data packet and extract the random number S. DPMAR S ACAR AC A Verification result of user identity certificate and public key Where the random number S ARDPM With random number S DPMAR Generate a communication key K with DPM based on the key generation algorithm. DPMAR And random number S ACAR With S ARAC Generate a key with AC using a key generation algorithm. A Communication key K ARAC If verification is successful, AR A Platform Certificate The platform's own unique identifier Platform integrity metrics Using communication key K DPMAR Encryption, yielding the encrypted result. And generate a random number S ARAC ,use Encrypt and send to AC A If verification fails, disconnect AR. A With AC A The connection.

[0037]

[0038] This concludes the cross-domain user authentication process.

[0039] Step 48, AC A Received AR A After receiving the data packet, check for random number defenses against replay attacks using the private key. Decrypt the data packet and extract the random number S. ARAC , with S ACAR Generate with AR through key generation algorithm A Communication key K ARAC AC A Platform Certificate The platform's own unique identifier Platform integrity metrics Using communication key K DPMAC Encryption, the encryption result is and Send to DPM.

[0040]

[0041]

[0042] Step 49, DPM receives AC A After receiving the data packet, check the random number to defend against replay attacks, using the communication key K. DPMAR and K DPMAC Decrypt the data packet and obtain and And on the consortium blockchain according to The system retrieves the corresponding platform certificate for platform identity authentication and platform integrity metric verification. If the certificate verification is successful, a platform certificate verification result is generated. and In addition, the platform certificate (UG) and the user identity certificate (DG) are compared to check if the platform certificate and user certificate are bound together to prevent man-in-the-middle attacks. If they are not bound, the connection is disconnected. DPM uses the communication key K. DPMAR right Encryption is performed using the communication key K. DPMAC right Encrypt the data and send the encrypted result to AC. A .

[0043]

[0044] Step 410, AC A Upon receiving the data packet from DPM, check for random number replay attack defenses and use the communication key K. DPMAC Decrypt the data packet to obtain the platform certificate verification result. Based on the verification results, appropriate access control will be implemented. If the platform certificate verification is successful, AC... A Allow AR A Join the trusted network; if verification fails, AC A AR is prohibited A Join a trusted network. AC A Forward the rest of the content to AR A .

[0045]

[0046] Step 411, AR A Received AC A After receiving the data packet, use the communication key K DPMAR Decrypt the data packet to obtain the platform certificate verification result. Based on the verification results, appropriate access control will be implemented. If the platform certificate verification is successful, AR A Join the trusted network; if verification fails, AR A Refuse to join trusted networks.

[0047] This concludes the platform identity authentication and platform integrity verification process within the domain.

[0048] Step 412, DPM according to AR A Access requirements (intra-domain authentication / cross-domain authentication) determine AR A Whether the platform certificate and identity certificate are broadcast and uploaded to the global blockchain PBC.

[0049] Figure 5 This is a schematic diagram illustrating the specific process of the cross-domain authentication method of the present invention, as shown below. Figure 5 As shown.

[0050] Step 51, AR A To AC B Initiate a cross-domain authentication request and retrieve the public key from the DPM public key group KG. DPM Choose a DPM public key K DPM1 Send to AR A .

[0051] AR A →AC B :K DPM1 (13)

[0052] Step 52, AC B Received AR A After receiving the data packet, extract the public key K. DPM1 Check if it has its own DPM public key group K. GDPM If it exists, then generate a random number S. ACDPM and N AC From DPM public key group KG DPM Choose a DPM public key K DPM2 and using DPM public key K DPM1 Encrypted User Identity Certificate Encryption result With K DPM2 Send to AR A If it does not exist, the connection will be closed.

[0053]

[0054] Step 53, AR A Received AC B After receiving the data packet, check for random number replay attack defense and extract the public key K. DPM2 Check if it has its own DPM public key group KG DPM If it exists, use the DPM public key K. DPM2 Encrypted User Identity Certificate Generate random number N AR And encrypt the result Send to AC B ;

[0055]

[0056] Step 54, AR A Received AC B After receiving the data packet, check for replay attack prevention using random numbers and generate a random number S.ARDPM , with AR A Public Key Encrypt and forward to DPM. If not found, disconnect.

[0057]

[0058] Step 55, AC B Received AR A After receiving the data packet, check for replay attack prevention using random numbers and generate a random number S. ACDPM , with AC B Public Key The rest of the data packet is encrypted and forwarded to DPM.

[0059]

[0060] Step 56, DPM receives AR A After receiving the data packet, check for random number defenses against replay attacks using the private key. Decrypt to obtain S ARDPM Generate random number S DPMAR , will S DPMAR and S ARDPM DPM and AR are generated using a key generation algorithm. A Communication key K DPMAR ; and use the private key Decrypt and obtain Based on global chain PBC Query and obtain the corresponding user identity certificate And verify the certificate's validity. If the certificate verification is successful, retrieve the AC from the certificate. B Public Key Generate user identity certificate verification result The random number S DPMAR And N1, user identity certificate verification results Use public key Send to AR after encryption A .

[0061]

[0062] Step 57, DPM receives AC B After receiving the data packet, check for random number defenses against replay attacks using the private key. Decrypt to obtain S ACDPM Generate random number S DPMAC , will S DPMAC and S ACDPM DPM and AC are generated using a key generation algorithm. B Communication key K DPMAC ; and use the private key Decrypt and obtain Based on global chain PBC Query and obtain the corresponding user identity certificate And verify the certificate's validity. If the certificate verification is successful, extract the AR from the certificate. A Public Key Generate user identity certificate verification result The random number S DPMAC And N2, user identity certificate verification results Use public key Send after encryption

[0063]

[0064] Step 58, AR A Upon receiving the data packet from DPM, check for replay attack prevention using random numbers and the private key. Decrypt and obtain S DPMAR and S DPMAR and S ARDPM DPM and AR are generated using a key generation algorithm. A Communication key K DPMAR Check AC B User identity certificate verification result If verification is successful, AR A Platform Certificate The platform's own unique identifier Platform integrity metrics Using communication key K DPMAR Encryption, yielding the encrypted result. And generate a random number S ARAC ,use Encrypt and send to AC B If verification fails, disconnect AC. B with AR A The connection.

[0065]

[0066] Step 59, AC B Upon receiving the data packet from DPM, check for replay attack prevention using random numbers and the private key. Decrypt and obtain S DPMAC and S DPMAC and S ACDPM DPM and AR are generated using a key generation algorithm. A Communication key KDPMAC Check AR A User identity certificate verification result If verification is successful, AC B Platform Certificate The platform's own unique identifier Platform integrity metric IM AC B Using communication key K DPMAC Encryption, yielding the encrypted result. And generate a random number S ACAR ,use Encrypted and sent to AR A If verification fails, disconnect AC. B with AR A The connection.

[0067]

[0068] This concludes the cross-domain user authentication process.

[0069] Step 510, AR A Received AC B After receiving the data packet, check for random number defenses against replay attacks using the private key. Decrypt to obtain S ARAC , with S ARAC DPM and AC are generated using a key generation algorithm. B Communication key K ACAC And forward the remaining data packets to DPM.

[0070] Step 511, AC B Received AR A After receiving the data packet, check for random number defenses against replay attacks using the private key. Decrypt to obtain S ARAC , with S ACAR DPM and AR are generated using a key generation algorithm. A Communication key K ACAC And forward the remaining data packets to DPM.

[0071]

[0072] Step 512, DPM receives AR A After receiving the data packet, check the random number to defend against replay attacks, using the communication key K. DPMAR Decrypt the data packet and obtain And on the global chain PBC according to The system retrieves the corresponding platform certificate for platform identity authentication and platform integrity metric verification. If the certificate verification is successful, a platform certificate verification result is generated. In addition, the platform certificate (UG) and the user identity certificate (DG) are compared to check if the platform certificate and user certificate are bound together to prevent man-in-the-middle attacks. If they are not bound, the connection is disconnected. DPM uses the communication key K. DPMAR right Encrypt the data and send the encrypted result to AR. A .

[0073]

[0074] Step 513, DPM receives AC B After receiving the data packet, check the random number to defend against replay attacks, using the communication key K. DPMAC Decrypt the data packet and obtain And on the global chain PBC according to The system retrieves the corresponding platform certificate for platform identity authentication and platform integrity metric verification. If the certificate verification is successful, a platform certificate verification result is generated. In addition, the platform certificate (UG) and the user identity certificate (DG) are compared to check if the platform certificate and user certificate are bound together to prevent man-in-the-middle attacks. If they are not bound, the connection is disconnected. DPM uses the communication key K. DPMAC right Encrypt the data and send the encrypted result to AC. B .

[0075]

[0076] Step 515, AC B Upon receiving the data packet from DPM, check for random number replay attack defenses and use the communication key K. DPMAC Decrypt the data packet to obtain the platform certificate verification result. Based on the verification results, appropriate access control will be implemented. If the platform certificate verification is successful, AC... B Allow AR A Cross-domain access to trusted domain B; if authentication fails, AC B AR is prohibited A Cross-domain access to trusted domain B.

[0077] At this point, the cross-domain authentication process for platform identity verification and platform integrity verification is complete.

[0078] The detailed descriptions listed above are merely specific descriptions of feasible embodiments of the present invention and are not intended to limit the scope of protection of the present invention. All equivalent embodiments or modifications made without departing from the spirit of the inventive technique should be included within the scope of protection of the present invention.

Claims

1. A method for cross-domain trusted network connection of industrial equipment based on multi-layer consortium blockchain, characterized in that: Design a CertChain structure to store user identity information and platform information, ensuring the secure storage of authentication information, providing security for cross-domain authentication protocols, and resisting man-in-the-middle attacks by binding user certificates and platform certificates; propose a five-element trusted cross-domain connection architecture suitable for cross-domain authentication by horizontally scaling the Trusted Connection Architecture (TCA); perform device registration, intra-domain authentication, and cross-domain authentication. The registration phase, which packages user identity information, platform information, and registration information for storage on the consortium blockchain, is the foundation for ensuring secure communication. The intra-domain authentication phase, which verifies local industrial equipment information, is the basis for cross-domain authentication. Cross-domain authentication is the key to ensuring that industrial equipment can reliably access other trusted domains across domains. Five-element trusted cross-domain connection architecture: The five-element trusted cross-domain connection architecture comprises four functional modules: user identity authentication, platform authentication, integrity measurement, and blockchain service, as well as five entities and trust domains. Access requester Access controller and trust domain Access requester Access controller and distributed policy manager The user authentication module is responsible for management within the distributed policy manager. Below, for the access requester or access controller The platform authentication module performs user authentication and handles network communication and access control between various components. Under the management of the Distributed Policy Manager (DPM), the module is responsible for verifying the identity of access requesters. or access controller Perform platform identity authentication and platform integrity verification; The integrity measurement module collects and verifies the integrity values ​​of each component of the platform, and sends the verification results to... The blockchain service module stores user identity information, platform identity information, and platform integrity metrics, and provides authentication information to the distributed policy manager, which acts as a trusted third party.

2. The method for cross-domain trusted network connection of industrial equipment based on multi-layer consortium blockchain according to claim 1, characterized in that: The CertChain structure includes: The CertChain stores two types of certificate transactions. CertChain consists of a block header and a block body. The block header includes the previous block hash, block number, version, timestamp, and hash root. The block body comprises multiple transactions, each representing a consortium blockchain certificate. These certificates are of two types: user identity certificates and platform certificates. These two types of certificates are used at different stages. The user identity certificate includes the certificate UID, holder ID, holder public key, and platform certificate ID set. The platform certificate ID set is the set of certificate IDs of the platform certificate bound to this user identity certificate. Platform certificate transactions include the certificate DID, holder ID, integrity metric IM, and user identity certificate ID set. The user identity certificate ID set is the set of certificate IDs of the user identity certificate bound to this platform certificate, while the integrity metric IM is used to measure whether the system or hardware / software is complete, reliable, and trustworthy during operation.

3. The method for cross-domain trusted network connection of industrial equipment based on multi-layer consortium blockchain according to claim 1, characterized in that: Intra-domain authentication protocol process; Step 41, Trust Domain Access requester Access controller to the same trusted domain Initiate an access authentication request message and generate challenge information. ,in Indicates the direction in which the message is sent; ； Step 42, response Access authentication requests and from the distributed policy manager public key group Choose one Public Key Send to ; ； Step 43, receive After receiving the data packet, extract the public key. Check if it has its own Public key group If it exists, then generate random numbers. and and use Public Key Encrypted User Identity Certificate Send it to If it does not exist, disconnect. ； Step 44, receive After receiving the data packet, check for replay attack defense using random numbers and generate random numbers. With user identity certificate Send them together after encryption ; ； Step 45, Received from After the data packet, check for random number defense against replay attacks using the private key. Decrypt and obtain , , and And on the consortium blockchain according to , Query and obtain the corresponding user identity certificate and And verify the validity of the certificate; If the certificate verification is successful, a user identity certificate verification result will be generated. and and extract the information from the certificates respectively. Public Key and Public Key ; Generate random numbers , , and ,Will Generate using a key generation algorithm and Communication key ;Will Generate using a key generation algorithm and Communication key The random number, user authentication certificate verification result, and public key are encrypted and returned to the user. ; ； ； Step 46, receive After receiving the data packet, use the private key. Decrypt the data packet and extract the random number. , Verification result of user identity certificate and public key , where random number With random numbers Generate and according to the key generation algorithm Communication key ; If the verification is successful, a random number will be generated. And encrypt it with the content ; If verification fails, disconnect. and The connection; ； Step 47, receive After receiving the data packet, check for random number defenses against replay attacks using the private key. Decrypt the data packet and extract the random number. , , Verification result of user identity certificate and public key , where random number With random numbers Generate and according to the key generation algorithm Communication key random numbers and Generate a key using a key generation algorithm. Communication key If the verification is successful, Platform Certificate The platform's own unique identifier Platform integrity metrics Use communication key Encryption, yielding the encrypted result. And generate random numbers ,use Encrypted to send ; If verification fails, disconnect. and The connection; ； The cross-domain authentication process for user identity verification has ended; Step 48, receive After receiving the data packet, check for random number defenses against replay attacks using the private key. Decrypt the data packet and extract the random number. ,and Generate a key using a key generation algorithm. Communication key ; Platform Certificate The platform's own unique identifier Platform integrity metrics Use communication key Encryption is performed, and the encryption result is: ,and Send to ; ； ； Step 49, receive After receiving the data packet, check the random number to defend against replay attacks, using the communication key. and Decrypt the data packet and obtain and And on the consortium blockchain according to , The system retrieves the corresponding platform certificate for platform identity authentication and platform integrity metric verification. If the certificate verification is successful, a platform certificate verification result is generated. and ; In addition, regarding platform certificates and user identity certificate Compare and check whether the platform certificate and user certificate are bound to each other to prevent man-in-the-middle attacks. If they are not bound, disconnect the connection. Use communication key right Encryption is performed using a communication key. right Encrypt and send the encryption result to ; ； Step 410, receive After receiving the data packet, check the random number to defend against replay attacks, using the communication key. Decrypt the data packet to obtain the platform certificate verification result. Based on the verification results, appropriate access control will be implemented. If the platform certificate verification is successful, allow Join the trusted network; if verification fails, prohibit Join a trusted network; Forward the rest of the content to ; ； Step 411, receive After receiving the data packet, use the communication key. Decrypt the data packet to obtain the platform certificate verification result. Based on the verification results, appropriate access control will be implemented. If the platform certificate verification is successful, Join the trusted network; if verification fails, Refuse to join trusted networks; At this point, the platform identity authentication and platform integrity verification process within the domain is complete; Step 412, according to Access demand determines Are the platform certificate and identity certificate broadcast and uploaded to the global blockchain? .

4. The method for cross-domain trusted network connection of industrial equipment based on multi-layer consortium blockchain according to claim 1, characterized in that: Cross-domain authentication protocol process: Step 51, Trust Domain Access requester To Trust Domain Access controller Initiate a cross-domain authentication request and from public key group Choose one Public Key Send to ; ； Step 52, receive After receiving the data packet, extract the public key. Check if it has its own Public key group If it exists, then generate random numbers. and ,from Public key group Choose one Public Key and use Public Key Encrypted User Identity Certificate encrypt the result and Send to If it does not exist, disconnect. ； Step 53, receive After receiving the data packet, check for random number replay attack defenses and extract the public key. Check if it has its own Public key group If it exists, use Public Key Encrypted User Identity Certificate Generate random numbers And encrypt the result Send to ; ； Step 54, receive After receiving the data packet, check for replay attack defense using random numbers and generate random numbers. ,and Public Key , Encrypted forwarding to If it does not exist, disconnect. ； Step 55, receive After receiving the data packet, check for replay attack defense using random numbers and generate random numbers. ,and Public Key The rest of the data packet is encrypted and forwarded to ; ； Step 56, receive After receiving the data packet, check for random number defenses against replay attacks using the private key. Decrypt and obtain Generate random numbers ,Will Generate using a key generation algorithm and Communication key ;and use the private key Decrypt and obtain In the global blockchain According to Query and obtain the corresponding user identity certificate And verify the validity of the certificate; If certificate verification is successful, retrieve from the certificate. Public Key Generate user identity certificate verification results ; random numbers and User identity certificate verification result Use public key Send after encryption ; ； Step 57, receive After receiving the data packet, check for random number defenses against replay attacks using the private key. Decrypt and obtain Generate random numbers ,Will Generate using a key generation algorithm and Communication key ;and use the private key Decrypt and obtain In the global blockchain According to Query and obtain the corresponding user identity certificate And verify the certificate's validity; if the certificate verification is successful, extract the certificate... Public Key Generate user identity certificate verification results ; random number and User identity certificate verification result Use public key Send after encryption ; ； Step 58, receive After receiving the data packet, check for random number defenses against replay attacks using the private key. Decrypt and obtain , and ,Will Generate using a key generation algorithm and Communication key ;examine User identity certificate verification result If the verification is successful, Platform Certificate The platform's own unique identifier Platform integrity metrics Use communication key Encryption, yielding the encrypted result. And generate random numbers ,use Encrypted to send ; If verification fails, disconnect. and The connection; ； Step 59, receive After receiving the data packet, check for random number defenses against replay attacks using the private key. Decrypt and obtain , and ,Will Generate using a key generation algorithm and Communication key ;examine User identity certificate verification result If the verification is successful, Platform Certificate The platform's own unique identifier Platform integrity metrics Use communication key Encryption, yielding the encrypted result. And generate random numbers ,use Encrypted to send ; If verification fails, disconnect. and The connection; ； At this point, the cross-domain authentication process for user identity verification is complete. Step 510, receive After receiving the data packet, check for random numbers to defend against replay attacks, using the private key. Decrypt and obtain ,and Generate using a key generation algorithm and Communication key and forward the remaining data packets to ; Step 511, receive After receiving the data packet, check for random number defenses against replay attacks using the private key. Decrypt and obtain ,and Generate using a key generation algorithm and Communication key and forward the remaining data packets to ; ； Step 512, receive After receiving the data packet, check the random number to defend against replay attacks, using the communication key. Decrypt the data packet and obtain And in the global blockchain According to The system retrieves the corresponding platform certificate for platform identity authentication and platform integrity metric verification. If the certificate verification is successful, a platform certificate verification result is generated. ; In addition, regarding platform certificates and user identity certificate Compare and check whether the platform certificate and user certificate are bound to each other to prevent man-in-the-middle attacks. If they are not bound, disconnect the connection. Use communication key right Encrypt and send the encryption result to ; ； Step 513, receive After receiving the data packet, check the random number to defend against replay attacks, using the communication key. Decrypt the data packet and obtain And in the global blockchain According to The system retrieves the corresponding platform certificate for platform identity authentication and platform integrity metric verification. If the certificate verification is successful, a platform certificate verification result is generated. ; In addition, regarding platform certificates and user identity certificate Compare and check whether the platform certificate and user certificate are bound to each other to prevent man-in-the-middle attacks. If they are not bound, disconnect the connection. Use communication key right Encrypt and send the encryption result to ; ； Step 515, receive After receiving the data packet, check the random number to defend against replay attacks, using the communication key. Decrypt the data packet to obtain the platform certificate verification result. Based on the verification results, appropriate access control will be implemented. If the platform certificate verification is successful, allow Cross-domain access to trusted domains If verification fails, prohibit Cross-domain access to trusted domains ; At this point, the cross-domain authentication process for platform identity verification and platform integrity verification is complete.

Images