Cross-domain authentication bridging method and system oriented to industrial Internet of Things interconnection

Abstract

The invention discloses a cross-domain authentication bridging method and system oriented to industrial Internet of Things interconnection, and belongs to the technical field of Internet of Things security, and the method comprises the steps of system initialization, cross-domain bridging, certificate verification, key exchange and secure communication, dynamic certificate updating and management and the like. According to the method, technical means such as ChaCha20, Poly1305, BLAKE2s, Ed25519, an elliptic curve Diffie-Hellman and the like are comprehensively utilized, a Bloom filter and a Merkle tree are utilized to realize incremental updating and rapid verification of a revoked list, and dynamic key generation and seamless switching are completed through domain division management. Therefore, the system has the characteristics of low time delay, high safety and fault tolerance, is suitable for large-scale industrial scenes, can remarkably reduce the bandwidth and calculation overhead, improves the equipment interconnection efficiency, enhances the safety, and is suitable for industrial field multi-domain collaboration.

Description

Technical Field

[0001] The present invention relates to the field of Internet of Things security technology, and particularly to cross-domain authentication and distributed trust management technology in the context of Industrial Internet of Things (IIoT); more specifically, it relates to a cross-domain authentication bridging method and system for industrial Internet of Things interconnection. Background Art

[0002] Currently, with the continuous advancement of industrial automation, a large number of devices (such as PLCs, sensors, robots, AGVs, etc.) in traditional factories are connected to the Industrial Internet of Things. However, different manufacturers or organizations often use independent Certification Authorities (CAs), and there is a lack of a unified trust mechanism for device certificates in cross-domain situations. At the same time, industrial devices generally have the characteristics of limited resources (computing power, bandwidth, memory, etc.) and are difficult to adapt to high-complexity or high-latency cryptographic algorithms and certificate management strategies. Although traditional security solutions using large keys such as RSA or ECC can provide sufficient security, they are prone to becoming bottlenecks when performing certificate updates and revocation verifications in a massive industrial device environment.

[0003] Therefore, it is considered to provide a cross-domain authentication bridging method and system for industrial Internet of Things interconnection to achieve efficient authentication and secure communication in industrial scenarios, so as to meet the high reliability and low latency requirements of industrial sites. Summary of the Invention

[0004] In view of the above technical problems, the present invention provides a cross-domain authentication bridging method and system for industrial Internet of Things interconnection. The domains are closely connected through data streams and interaction logics to form a unified authentication bridging architecture, which helps to achieve efficient authentication and secure communication in industrial scenarios and meet the high reliability and low latency requirements of industrial sites.

[0005] To achieve the above object, the technical solution adopted by the present invention is as follows:

[0006] In a first aspect, the present invention provides a cross-domain authentication bridging method for industrial Internet of Things interconnection, and the method includes the following steps:

[0007] S1. Perform initialization. When a device in the local domain accesses for the first time, it requests registration from the certification authority; the certification authority generates a device certificate and signs it for the device, and stores the device certificate and the certificate chain locally on the device.

[0008] S2. Perform cross-domain bridging. Connect the certificate chain of domain A and the certificate chain of domain B through a bridging certificate.

[0009] S3. Perform certificate verification. When a device performs cross-domain authentication, the certification authority of domain B first verifies the validity of the device certificate of domain B, and then the device of domain A verifies whether the certificate chain of the device of domain B is valid.

[0010] S4. Perform key exchange and secure communication. After the certificate chain verification is completed, allocate a temporary session key for the device in Domain B, and perform key exchange between the device in Domain B and the device in Domain A; and use lightweight cryptographic algorithms to ensure data confidentiality and integrity.

[0011] Furthermore, the method further includes:

[0012] S5. Perform dynamic certificate update and management. When the device certificate is approaching expiration or is revoked, send an update message to the certification authority in the local domain, allocate a new certificate for the device, and update the revocation list.

[0013] Furthermore, in S1, the device certificate includes the public key, signature information, and domain parameters of the device; the certification authority in the local domain signs the device certificate using the Ed25519 algorithm; when a new device is allocated a certificate, the certification authority in the local domain adds the hash value of the new device certificate to the leaf node of the merkle tree certificate chain maintained by the certification authority in the local domain.

[0014] Furthermore, in S2, issue a bridging certificate through a common and trusted neutral certification authority. The bridging certificate contains the root certificate information of Domain A and Domain B, enabling mutual trust between the root certificates of Domain A and Domain B; and use the Ed25519 algorithm to sign the bridging certificate.

[0015] Furthermore, in S3, when a device in Domain B needs cross-domain authentication, send a cross-domain request to the certification authority in Domain B. After obtaining the request, the certification authority in Domain B verifies the validity of the bridging certificate through a Bloom filter and a merkle tree. If it is not revoked, the certification authority in Domain B sends the cross-domain request message to the device in Domain A; otherwise, it rejects and returns a message to regenerate the certificate. If the bridging certificate is valid, the device in Domain A verifies the integrity of the certificate chain of the device in Domain B. If it is not tampered with, subsequent operations are performed; otherwise, it is rejected.

[0016] Furthermore, in S4, generate a temporary session key for the device in Domain B through the device identifier and domain parameters; and perform key exchange through the Diffie-Hellman encryption protocol.

[0017] Furthermore, in S4, use lightweight cryptographic algorithms to ensure data confidentiality and integrity, including:

[0018] 1) Use the ChaCha20 algorithm to perform block stream encryption on the data to be transmitted;

[0019] 2) Calculate the integrity tag of the encrypted data through the Poly1305 message authentication code, and the receiving end performs integrity verification accordingly.

[0020] Furthermore, in S5, when performing dynamic certificate update and management, achieve incremental synchronization through the following steps:

[0021] 1) When the certification authority issues a new certificate, it generates an incremental package containing the differential of the Bloom filter bit array or the updated nodes of the Merkle tree;

[0022] 2) The local domain certification authority distributes the incremental package to the device;

[0023] 3) The device only updates the affected bit array or subtree part without downloading the complete revocation list.

[0024] In a second aspect, the present invention also provides a cross - domain authentication bridging system for industrial Internet of Things interconnection, which is applied to the above - mentioned cross - domain authentication bridging method for industrial Internet of Things interconnection. The system includes:

[0025] An initialization module, which is used to initialize the devices in the local domain. When a device in the local domain accesses for the first time, it requests registration from the certification authority. The certification authority generates a device certificate for the device and signs it, and stores the device certificate and the certificate chain locally on the device;

[0026] A cross - domain bridging module, which is used to perform cross - domain bridging and connect the certificate chains of domain A and domain B through a bridging certificate;

[0027] A certificate verification module, which is used to verify certificates. When a device performs cross - domain authentication, the certification authority of domain B first verifies the validity of the device certificate in domain B, and then the device in domain A verifies whether the certificate chain of the device in domain B is valid;

[0028] A key exchange and secure communication module, which is used to perform key exchange and secure communication. After the certificate chain verification is completed, it assigns a temporary session key to the device in domain B, and the device in domain B exchanges keys with the device in domain A; and uses lightweight cryptographic algorithms to ensure data confidentiality and integrity.

[0029] Furthermore, the system further includes:

[0030] A dynamic certificate update and management module, which is used to perform dynamic certificate update and management. When the device certificate is approaching expiration or is revoked, it sends an update message to the local domain certification authority, assigns a new certificate to the device and updates the revocation list.

[0031] Compared with the prior art, the present invention has at least the following beneficial technical effects:

[0032] 1. The present invention provides a cross - domain authentication bridging method and system for industrial Internet of Things interconnection, which helps to achieve efficient authentication and secure communication in industrial scenarios; and meets the high - reliability and low - latency requirements of industrial sites.

[0033] 2. The present invention combines lightweight encryption algorithms (ChaCha20, Poly1305, BLAKE2s) with Ed25519 and elliptic curve Diffie-Hellman cross-domain key exchange, uses Bloom Filter and Merkle tree to achieve incremental update and fast verification of revocation lists, and completes dynamic key generation and seamless switching through domain-by-domain management. It has the characteristics of low latency, high security and fault tolerance, is suitable for large-scale industrial scenarios, can significantly reduce bandwidth and computing overhead, improve device interconnection efficiency, and enhance security, and is suitable for multi-domain collaboration in industrial fields.

[0034] Other features and advantages of the present invention will be described in the following specification, and, in part, will be obvious from the specification, or will be understood by implementing the present invention. The objectives and other advantages of the present invention can be achieved and obtained by the structures specifically pointed out in the written specification and the drawings.

[0035] The following will, through the drawings and embodiments, make a further detailed description of the technical solutions of the present invention. Description of the Drawings

[0036] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the drawings in the following description are some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0037] The drawings are used to provide a further understanding of the present invention, and constitute a part of the specification. They are used together with the embodiments of the present invention to explain the present invention, and do not constitute a limitation to the present invention.

[0038] Figure 1 It is a schematic flowchart of a cross-domain authentication bridging method for industrial Internet of Things interconnection provided by an embodiment of the present invention.

[0039] Figure 2 It is a schematic diagram of dynamic certificate update and management provided by an embodiment of the present invention.

[0040] Figure 3 It is a schematic overall timing diagram of the method provided by an embodiment of the present invention. Detailed Embodiments

[0041] To make the objectives, technical solutions and advantages of the embodiments of the present invention clearer, the following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the drawings in the embodiments of the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention.

[0042] In the description of the present invention, it should be noted that: in some processes described in the specification and drawings of this application, a plurality of operations appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order in which they appear herein or may be executed in parallel. In addition, various serial numbers, etc. are only for descriptive purposes and cannot be understood as indicating or implying relative importance.

[0043] Therefore, the following detailed description of the embodiments of the present invention provided in the drawings is not intended to limit the scope of the claimed invention, but merely represents selected embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts fall within the scope of protection of the present invention.

[0044] The important terms and constraints in the embodiments of the present invention are as follows:

[0045] Device certificate: A device certificate is a public key certificate issued by a certification authority (CA) when a device (such as a sensor, PLC, robot, etc.) is initialized, and includes the public key of the device, the device identifier (DevID), the validity period, signature information, etc.

[0046] Domain parameter: A parameter is configuration data related to the domain where the device is located, and includes information such as the unique identifier of the domain (DomainID), version number, access control policy (Policy), encryption algorithm selection, domain public key, validity period, domain salt value, etc.

[0047] Bridge certificate: A bridge certificate is signed by the certification authority (CA-A) of the source domain and is a certificate connecting the source domain and the target domain. The bridge certificate plays a role in trust transfer in cross-domain authentication to ensure that the device can establish trust between different domains.

[0048] Bloom filter: A Bloom filter is an efficient probabilistic data structure used to quickly detect whether a certificate has been revoked. It maps the revoked certificate identifier through multiple hash functions and can quickly determine whether a certain certificate is in the revocation list.

[0049] Merkle tree: A Merkle tree is a binary tree data structure. Each leaf node stores the hash value of the certificate, and each parent node stores the combination of the hashes of its child nodes. The Merkle tree is used to verify the integrity of the certificate revocation information.

[0050] See Figure 1 As shown, the embodiments of the present invention provide a cross-domain authentication bridging method for industrial Internet of Things interconnection, and this method mainly includes the following steps:

[0051] S1. Perform initialization. When a device in this domain accesses for the first time, it requests registration from the authentication authority. The authentication authority generates a device certificate and signs it for the device, and stores the device certificate and the certificate chain locally on the device.

[0052] S2. Perform cross - domain bridging. Connect the certificate chain of domain A and the certificate chain of domain B through the bridging certificate.

[0053] S3. Perform certificate verification. When the device conducts cross - domain authentication, the authentication authority of domain B first verifies the validity of the device certificate in domain B, and then the device in domain A verifies whether the certificate chain of the device in domain B is valid.

[0054] S4. Perform key exchange and secure communication. After the certificate chain verification is completed, a temporary session key is assigned to the device in domain B, and the device in domain B and the device in domain A conduct key exchange; and use lightweight cryptographic algorithms to ensure data confidentiality and integrity.

[0055] Furthermore, as shown in Figure 2 the method further includes:

[0056] S5. Perform dynamic certificate update and management. When the device certificate is approaching expiration or is revoked, send an update message to the authentication authority of this domain, and assign a new certificate to the device and update the revocation list.

[0057] Next, in combination with Figures 1-3 shown below, the working principle and implementation manner of the present invention will be introduced in detail:

[0058] In a specific embodiment, in step S1 above, system initialization is performed. When the system is deployed, the factory authentication authority (CA) generates a root certificate and signs it for the domain CA. Record the domain parameter DomParam and the device identifier DevID.

[0059] When a device in domain A registers, the certificate generation process is first completed through interaction with the authentication authority of domain A (CA_A). The initial certificate generated by the device contains the public key Pub i , the signature information Sign i and the domain parameter DomParam (where i represents device i):

[0060] Cert i ={DevID i , Pub i , Sign i , Expiry, DomParam}

[0061] Where:

[0062] Sign i =Sign CA (DevID i||Pub i ||Expiry||DomParam), and use Ed25519 to generate

[0063] a signature.

[0064] Expiry indicates the validity period of the certificate.

[0065] The Ed25519 algorithm is an implementation of the Elliptic Curve Digital Signature Algorithm (ECDSA), which is based on the Elliptic Curve Curve25519.

[0066] The domain parameter DomParam includes the domain ID, domain version number, access control policy (Policy), in-domain algorithm selection, domain salt value, validity period, and domain public key. Among them:

[0067] The domain ID is used to identify the domain, ensuring that the device can perform appropriate authentication and encryption operations according to the current domain it is in. The domain version number helps the device identify changes in old and new domain parameters, ensuring that the device can correctly update its session key during domain switching and avoid using expired keys or policies. According to the access control policy, the device will selectively update permissions when crossing domains (such as changing from read-only to writeable permissions). At the same time, the policy also determines whether the device can participate in cross-domain authentication and whether additional permission verification is required. The algorithm selection ensures that the device can use the encryption algorithm allowed by the target domain for data communication after crossing domains, while avoiding unsupported algorithms or algorithm versions. The domain salt value is a randomly generated salt value used to enhance the randomness in the Key Derivation Function (KDF) process and avoid conflicts in session keys generated by different domains. The validity period defines the validity period of the domain parameter. The device can only use the relevant keys, policies, and authentication information of this domain within the validity period and needs to be updated after expiration. The domain public key or the root certificate of the domain is used to authenticate and sign devices, services, or gateways within the domain. The device uses this public key to verify the validity of certificates and bridging certificates within the domain.

[0068] Device identifier:

[0069] DevID i = BLAKE2s(DeviceInfo i )

[0070] Among them, BLAKE2s is a cryptographic hash algorithm and one of the variants of the BLAKE2 family. DeviceInfo i represents the hardware serial number of the device.

[0071] The system can transmit information such as DomParam to the edge gateway through a secure channel and store it in a traceable database when needed to achieve consistency in distribution and verification.

[0072] In a specific embodiment, in the above step S2, in order to enable the devices in domain A and domain B to trust each other, it is necessary to connect the certificate chains of domain A and domain B through a bridging certificate. A bridging certificate is issued by a common and trusted neutral CA, enabling the root certificates of domain A and domain B to trust each other. This method signs the bridging certificate through Ed25519. Specifically, it includes:

[0073] ① Bridging certificate generation: The bridging CA generates a bridging certificate based on the received root certificates of domain A and domain B. The bridging certificate contains the following content: certificate version, certificate issuer, validity period, public key of the bridging CA, hash of the root certificate of domain A, public key of domain A, hash of the certificate of domain B, public key of domain B, and signature of the bridging CA.

[0074] ② Bridging certificate signature:

[0075] Sig = Sign(sk, H(Cert))

[0076] Where Sign represents the signature operation using the private key, and H(Cert) represents the hash value of the bridging certificate. Here, the signature algorithm selects the Ed25519 algorithm; sk represents the private key.

[0077] In a specific embodiment, in the above step S3, when the device performs cross-domain authentication, the CA in domain B first verifies the validity of the device certificate in domain B, and then the device in domain A verifies whether the certificate chain of the device in domain B is valid to ensure that the certificate is not expired, revoked, or tampered with. Specifically, it includes:

[0078] During cross-domain authentication, the device needs to verify the received certificate to ensure the integrity of the certificate chain. Bloom filters and Merkle tree technologies are used to quickly and efficiently verify whether the certificate has been revoked.

[0079] Revoked certificate check: After receiving the cross-domain request, the CA in domain B uses a Bloom filter to verify the timeliness of the certificate. The process of Bloom filter query is as follows:

[0080] BloomFilter(H(CertID)) = 1

[0081] If the return value is 1, it means the certificate may have been revoked, and the secondary verification of the Merkle tree is continued.

[0082] Merkle tree secondary verification: The Merkle tree is used to store the hash values of revoked certificates. Each time a certificate is revoked, the hash value of the leaf node of the Merkle tree changes, and the updated hash value is passed to the parent node in turn. Calculate whether it matches the hash value of the root node:

[0083] RootHash = Hash(ParentHash 1||......||ParentHash n )

[0084] If the verification passes, proceed to the subsequent steps; otherwise, reject and send a certificate update message to the cross-domain application device in this domain.

[0085] The CA in Domain B sends the received cross-domain request message M (including the certificate chain of its device certificate, intermediate certificate, and root certificate for cross-domain trust chain verification) to the device in Domain A together with the bridging certificate. The device in Domain A performs a decryption and signature verification operation based on the public key, recalculates whether it is the same as the signature value. If it is exactly the same, the signature verification is successful and meets the cross-domain integrity requirements. If it is invalid, cross-domain authentication is rejected.

[0086] In a specific embodiment, in step S4 above, after the certificate chain verification is completed, a temporary session key is assigned to the device in Domain B. The devices in Domains B and A perform a key exchange through Diffie-Hellman to generate a shared session key. The ChaCha20 encryption algorithm is used to ensure data confidentiality, and the Poly1305 message authentication code (MAC) is used to ensure data integrity; the key required for data encryption is derived from the dynamically generated temporary key. This step specifically includes:

[0087] 1. Session key derivation:

[0088] SessionKey i = KDF(MasterKey, DevID i ||DomParam j )

[0089] Where KDF is a key derivation function based on the BLAKE2s-HMAC architecture; MasterKey is the master key of the factory CA and is used as the core seed of KDF.

[0090] 2. Key exchange:

[0091] k AB = a × B = b × A

[0092] Where a is the private key of device A and the public key is A. b is the private key of device B and the public key is B. Calculate the shared key k through Elliptic Curve Diffie-Hellman AB .

[0093] 3. Encryption and signature:

[0094] (1). ChaCha20 encryption:

[0095] KeyStreamBlock = ChaCha20(K, N, C)

[0096] Among them, K is a 256-bit key, N is a 64-bit random value, and C is a 64-bit counter. KeyStreamBlock is the generated key stream.

[0097]

[0098] After multiple rounds of iteration, a pseudo-random key stream is generated and XORed with the plaintext to complete the encryption.

[0099] (2). Poly1305 Authentication Code:

[0100] MAC = Poly1305(KeyStreamBlock, Ciphertext)

[0101] MAC is used to verify the integrity of the encrypted data. If the verification fails, this data packet is discarded or a retransmission is requested.

[0102] In a specific embodiment, in the above step S5, the bridging certificate is synchronized regularly to ensure the validity of the trust chain between domain A and domain B. Combining the Bloom filter and the Merkle tree realizes the storage of revoked certificate identifiers, supporting dynamic certificate update and revocation; specifically including:

[0103] 1. Revocation List Storage:

[0104] ① Bloom Filter Update:

[0105] Index j = H j (Cert ID ) mod Z (j = 1, 2,....., k)

[0106] Among them, Cert ID is the identifier of the revoked certificate, H j is the j-th hash function used by the Bloom filter, and Z is the size of the bit array of the Bloom filter. k is the number of hash functions used, usually set to multiple to improve query accuracy and reduce false positives. Through the above update, the corresponding position in the Bloom filter will be marked as 1, indicating that the certificate has been revoked. After the device receives the revocation delta package, it will update the Bloom filter and only update the affected part, avoiding downloading the complete revocation list and significantly saving bandwidth.

[0107] ② Merkle Tree Update:

[0108] The Merkle tree is a structure used to verify data integrity and can efficiently verify large-scale data. In the present invention, the Merkle tree stores the hash value of the revoked certificate as a secondary verification method to prevent false positives. When a certain certificate is revoked, the Merkle tree will perform the following update:

[0109] Leaf Node Update: Revoking a certificate causes a change in the corresponding leaf node hash value. Based on the identifier (CertID) of the revoked certificate, assuming the position of the certificate in the tree is leaf node p, the device recalculates the hash value of the leaf node corresponding to the certificate:

[0110] Leaf p =Hash(CertID p )

[0111] Parent Node Update: When the leaf node hash is updated, the hash value of the parent node also needs to be updated. The formula for updating the parent node hash is:

[0112] ParentHash=Hash(LeftChildHash||RightChildHash)

[0113] where LeftChildHash and RightChildHash are the hash values of the left and right child nodes of the parent node respectively. The device will start from the affected leaf node and gradually update the hash values of all parent nodes upwards until the root node of the tree is updated.

[0114] 2. Incremental Revocation Package Format:

[0115] The incremental revocation package is sent to the local CA through TLS secure transmission. The CA only needs to update the affected part to avoid excessive bandwidth consumption caused by downloading the full revocation list.

[0116] The incremental revocation package contains the following parts:

[0117] DeltaUpdate={BloomDiff, MerkleNodeUpdate, Timestamp}

[0118] where: BloomDiff represents the bit array difference of the Bloom filter, and MerkleNodeUpdate represents the set of Merkle nodes that need to be updated.

[0119] 3. Differential Synchronization:

[0120] After receiving the incremental revocation package, the local CA only updates the affected part, thus avoiding the transmission of the full revocation list and significantly reducing bandwidth consumption.

[0121] Furthermore, the method of the present invention also includes a fault tolerance and security mechanism:

[0122] 1) When the Bloom filter makes a misjudgment, a Merkle tree is introduced to store the revocation certificate and the revocation node information path for secondary confirmation, and the unrevoked certificates are temporarily added to the whitelist;

[0123] 2) When conflicts occur during the update of the Merkle tree or the write is interrupted due to a power outage, support fallback based on the root hash snapshot of the latest signature;

[0124] 3) In the case of network disconnection or emergency shutdown in the industrial workshop, locally cache the incremental package or hash snapshot, and perform batch synchronization after the network is restored.

[0125] From the description of the above embodiments, those skilled in the art can know that the embodiments of the present invention provide a cross-domain authentication bridging method for industrial Internet of Things interconnection, which combines lightweight encryption algorithms (ChaCha20, Poly1305, BLAKE2s) with Ed25519 and elliptic curve Diffie-Hellman cross-domain key exchange, uses Bloom filters and Merkle trees to achieve incremental update and fast verification of revocation lists, and completes dynamic key generation and seamless switching through domain division management, enabling the system to have low latency, high security and fault tolerance characteristics, suitable for large-scale industrial scenarios, significantly reducing bandwidth and computing overhead and improving device interconnection efficiency, and enhancing security, suitable for multi-domain collaboration in industrial sites.

[0126] Furthermore, the embodiments of the present invention also provide a cross-domain authentication bridging system for industrial Internet of Things interconnection, which is applied to the above-mentioned cross-domain authentication bridging method for industrial Internet of Things interconnection. The system includes:

[0127] An initialization module, used for initializing devices in the local domain. When a device in the local domain accesses for the first time, it requests registration from the certification authority. The certification authority generates a device certificate for the device and signs it, and stores the device certificate and the certificate chain locally on the device;

[0128] A cross-domain bridging module, used for cross-domain bridging, connecting the certificate chains of domain A and domain B through a bridging certificate;

[0129] A certificate verification module, used for certificate verification. When a device performs cross-domain authentication, the certification authority in domain B first verifies the validity of the device certificate in domain B, and then the device in domain A verifies whether the certificate chain of the device in domain B is valid;

[0130] A key exchange and secure communication module, used for key exchange and secure communication. After the certificate chain verification is completed, a temporary session key is assigned to the device in domain B, and the device in domain B exchanges keys with the device in domain A; and uses lightweight cryptographic algorithms to ensure data confidentiality and integrity;

[0131] A dynamic certificate update and management module, used for dynamic certificate update and management. When the device certificate is close to expiration or revoked, it sends an update message to the local domain certification authority, assigns a new certificate to the device and updates the revocation list.

[0132] An inter - domain authentication bridging system for industrial Internet of Things (IIoT) interconnection provided by an embodiment of the present invention realizes cross - domain authentication, certificate management, and encrypted communication among devices in a reasonable and efficient IIoT environment based on CA bridging. The system uses multiple modules to cooperate with each other to ensure that devices communicate securely and trustworthily between multiple domains. Its implementation principle, technical effects produced are the same as those of the foregoing method embodiments. For the sake of brief description, for the parts not mentioned in this embodiment, reference can be made to the corresponding content in the foregoing method embodiments, and details will not be repeated here.

[0133] Those skilled in the art should understand that the embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present invention can take the form of a computer program product implemented on one or more computer - usable storage media (including but not limited to disk storage, CD - ROM, optical storage, etc.) containing computer - usable program code.

[0134] It should be noted that the word "comprising" does not exclude the presence of components or steps not listed in the claims. The word "a" or "an" preceding a component does not exclude the presence of a plurality of such components. The present invention can be realized by means of hardware including several different components and by means of a suitably programmed computer.

[0135] The various embodiments in this specification are described in a progressive manner, with each embodiment highlighting the differences from other embodiments. For the same or similar parts among the various embodiments, reference can be made to each other.

[0136] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present invention. Various modifications to these embodiments will be obvious to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to the embodiments shown herein, but will be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A cross-domain authentication bridging method for industrial Internet of Things interconnection, characterized in that: The method includes: S1. Initialization: When a device in this domain accesses for the first time, it requests registration from a certification authority; the certification authority generates and signs a device certificate for the device, and stores the device certificate and certificate chain locally on the device; S2. Perform cross-domain bridging and connect the certificate chain of domain A and the certificate chain of domain B through a bridging certificate. S3. Perform certificate verification. When the device performs cross-domain authentication, the certification authority of domain B first verifies the validity of the device certificate of domain B, and then the device of domain A verifies whether the certificate chain of the device of domain B is valid. S4. Perform key exchange and secure communication. After the certificate chain verification is completed, a temporary session key is assigned to the B domain device, and the B domain device exchanges keys with the A domain device; and a lightweight cryptographic algorithm is used to ensure data confidentiality and integrity.

2. According to a cross-domain authentication bridging method for industrial Internet of Things interconnection according to claim 1, it is characterized in that: The method further includes: S5. Perform dynamic certificate update and management. When the device certificate is close to expiration or is revoked, send an update message to the domain certification authority to assign a new certificate to the device and update the revocation list.

3. According to a cross-domain authentication bridging method for industrial Internet of Things interconnection according to claim 1, it is characterized in that: In S1, the device certificate includes the public key, signature information, and domain parameters of the device; the domain certification authority uses the Ed25519 algorithm to sign the device certificate; when a new device is assigned a certificate, the domain certification authority adds the hash value of the new device certificate to the leaf node of the merkle tree certificate chain maintained by the domain certification authority.

4. According to a cross-domain authentication bridging method for industrial Internet of Things interconnection according to claim 1, it is characterized in that: In S2, a common, trusted neutral certification authority issues a bridging certificate, which contains the root certificate information of domain A and domain B, so that the root certificates of domain A and domain B are mutually trusted; The bridge certificate is signed using the Ed25519 algorithm.

5. According to claim 4, a cross-domain authentication bridging method for industrial Internet of Things interconnection is characterized in that: In S3, when the B-domain device needs cross-domain authentication, it sends a cross-domain request to the certification authority of the B-domain. After receiving the request, the certification authority of the B-domain verifies the validity of the bridge certificate through the Bloom filter and the merkle tree. If the certificate is not revoked, the certification authority of the B-domain sends the cross-domain request message to the A-domain device. Otherwise, it is rejected and a message for regenerating the certificate is returned. If the bridge certificate is valid, the device in domain A verifies the integrity of the certificate chain of the device in domain B. If it has not been tampered with, it will proceed with subsequent operations, otherwise it will be rejected.

6. According to a cross-domain authentication bridging method for industrial Internet of Things interconnection according to claim 1, it is characterized in that: In S4, a temporary session key is generated for the B domain device using the device identifier and domain parameters; and key exchange is performed using the Diffie-Hellman encryption protocol.

7. According to a cross-domain authentication bridging method for industrial Internet of Things interconnection according to claim 1, it is characterized in that: In S4, a lightweight cryptographic algorithm is used to ensure data confidentiality and integrity, including: 1) Use the ChaCha20 algorithm to perform block stream encryption on the data to be transmitted; 2) The integrity tag of the encrypted data is calculated through the Poly1305 message authentication code, and the receiving end performs integrity verification based on it.

8. A cross-domain authentication bridging method for industrial Internet of Things interconnection according to claim 2, characterized in that: In S5, when dynamic certificate update and management is performed, incremental synchronization is achieved through the following steps: 1) When the certification authority issues a new certificate, it generates an incremental packet containing the Bloom filter bit array difference or the Merkle tree update node; 2) The domain authentication authority sends the incremental package to the device; 3) The device updates only the affected bit array or subtree portion without downloading the full revocation list.

9. A cross-domain authentication bridging system for industrial Internet of Things interconnection, characterized in that: When applied, a cross-domain authentication bridging method for industrial Internet of Things interconnection according to any one of claims 1 to 8 is executed, and the system includes: The initialization module is used to initialize the devices in this domain. When a device in this domain accesses for the first time, it requests registration from the certification authority. The certification authority generates a device certificate for the device and signs it, and stores the device certificate and certificate chain locally on the device. The cross-domain bridging module is used to perform cross-domain bridging and connect the certificate chain of domain A and the certificate chain of domain B through a bridging certificate; The certificate verification module is used to perform certificate verification. When a device performs cross-domain authentication, the certification authority of domain B first verifies the validity of the device certificate of domain B, and then the device of domain A verifies whether the certificate chain of the device of domain B is valid; The key exchange and secure communication module is used for key exchange and secure communication. After the certificate chain verification is completed, a temporary session key is allocated to the B domain device, and the B domain device exchanges keys with the A domain device; and a lightweight cryptographic algorithm is used to ensure data confidentiality and integrity.

10. A cross-domain authentication bridging system for industrial Internet of Things interconnection according to claim 9, characterized in that: The system also includes: The dynamic certificate update and management module is used to perform dynamic certificate update and management. When the device certificate is about to expire or is revoked, an update message is sent to the domain certification authority to allocate a new certificate to the device and update the revocation list.

Images