Proxy re-signature-based cross-heterogeneous domain authentication method applied to industrial Internet of Things

Abstract

The invention discloses a cross-heterogeneous domain authentication method based on proxy re-signature applied to industrial Internet of Things, which comprises the following steps: Internet of Things equipment generates an anonymous identity, and the anonymous identity is verified and stored by an authentication center; in the cross-domain authentication stage, the equipment performs cross-domain authentication through an anonymous identity, and an edge server performs proxy re-signature; and in the batch cross-domain authentication stage, the cross-domain authentication problem of multiple devices is solved, and the efficiency of the production process is improved. According to the method, the certificateless cryptosystem is adopted to generate the anonymous identity, a dynamic anonymous identity updating mechanism is introduced to ensure security identity verification and privacy protection of the equipment, a batch authentication strategy is used for reducing communication overhead and improving authentication efficiency, and formalized verification further proves the correctness of security certification. According to the method, privacy, non-linkability, non-repudiation and external aggression resistance are ensured, and more functions are provided under the condition of keeping similar overhead.

Description

A cross-heterogeneous domain authentication method based on proxy re-signature applied in the Industrial Internet of Things Technical Field

[0001] This invention relates to IoT signature and authentication technology, specifically to a cross-heterogeneous domain authentication method based on proxy re-signature applied in the Industrial Internet of Things. Background Technology

[0002] With the accelerating pace of innovation in smart technologies, the Industrial Internet of Things (IIoT) plays a crucial role in driving the global development of the Internet of Things. This IIoT architecture processes massive, high-speed data streams generated by end devices, which typically need to meet stringent security or compliance standards. In IIoT systems, end devices are usually distributed across multiple management domains, each coordinated by a domain server. For example, in automotive manufacturing, a robot from supplier A might need to access sensor data from supplier B to optimize the production process. The use of independent authentication schemes between different domains presents interoperability challenges for devices collaborating across domains. However, existing solutions cannot guarantee data security and privacy. Therefore, secure collaboration requires a cross-domain authentication scheme that strikes a balance between efficiency and privacy protection.

[0003] Current cross-domain authentication schemes face key technical challenges. Different administrative domains typically deploy their own intra-domain authentication schemes, including Public Key Infrastructure (PKI), where reliable Certificate Authorities (CAs) assign digital credentials to devices; and Identity-Based Cryptography (IBC), where a trusted Key Generation Center (KGC) selects a private key for a device based on its identifier. Meanwhile, certificateless public-key cryptography avoids reliance on traditional certificates. Interoperability barriers arise when heterogeneous domains exchange resources. Although several cross-domain authentication schemes have been proposed to protect device identities and ensure secure data exchange, several issues remain.

[0004] Unlike traditional cross-domain authentication, heterogeneous IIoT scenarios are characterized by the fact that the cryptographic systems used in different domains are often incompatible (e.g., PKI, IBC, CLC). Differences in cryptographic design, parameter configuration, and verification mechanisms mean that credentials are only valid within their native domain. Traditional solutions primarily focus on how to transfer trust between parties, while heterogeneous environments must simultaneously address cross-system interoperability and many other challenges, including privacy protection, autonomous identity updates, and scalable batch authentication for a large number of devices.

[0005] Current cross-heterogeneous domain authentication methods incur high computational and communication overhead, which can lead to data response delays and hinder collaborative production between heterogeneous domains. Furthermore, the long-term exposure or traceability of device identities during the cross-domain authentication phase poses a security threat to the target device. Therefore, identity anonymity is a fundamental requirement for ensuring the security of industrial systems. During the anonymous identity pre-generation process, devices must simultaneously store both the anonymous and real identities, increasing storage overhead and potentially wasting resources.

[0006] In practical Industrial Internet of Things (IIoT) deployments, heterogeneous domains often face latency and privacy risks during mutual authentication, necessitating a lightweight framework to address these limitations of existing solutions. Unlike traditional cross-domain environments that rely on unified authentication infrastructure and centralized trust management, heterogeneous cross-domain scenarios in IIoT involve multiple cryptographic systems, inconsistent identity formats, and decentralized trust models. These differences introduce new challenges in achieving interoperability, two-way authentication, and dynamic identity privacy.

[0007] To address existing cross-domain authentication schemes, Chinese patent application CN116827584A proposes a blockchain-based method for certificate-free anonymous cross-domain authentication of IoT devices. The main focus is on achieving certificate-free anonymous cross-domain authentication for IoT devices. It leverages blockchain technology, which is suitable for scenarios with "multiple trust domains, low trust levels, and low real-time requirements," to solve the authentication problems of IoT devices facing resource constraints, high real-time demands, and high dynamism. However, in this solution, the key generation center needs to write most of the information to the blockchain through a blockchain proxy server, making dynamic device management extremely difficult. Secondly, although the scheme employs a pseudonym mechanism, centralized storage of the pseudonym list poses a single point of privacy leakage risk and lacks a design for dynamic anonymous updates.

[0008] Chinese patent application CN118214563A discloses a blockchain-based cross-domain IoT device identity authentication method and system, solving the problems of expensive and cumbersome certificate management, authentication efficiency, and single point of failure in cross-domain identity authentication. However, as seen in the architecture diagram, in the authentication problem across multiple domains, IoT devices in each domain are uniformly managed by a trusted organization and key generation center. As the number of domains increases, the number of IoT devices also increases, leading to centralized privacy leakage issues. Furthermore, the authentication process involves multiple blockchain interactions, resulting in a decrease in real-time performance. Summary of the Invention

[0009] Purpose of the invention: The purpose of this invention is to address the shortcomings of existing technologies and provide a cross-heterogeneous domain authentication method based on proxy re-signature for application in the Industrial Internet of Things.

[0010] Technical solution: The present invention provides a cross-heterogeneous domain authentication method based on proxy re-signature in the Industrial Internet of Things, comprising the following steps:

[0011] Step (1): System initialization. Participating industrial domains negotiate several initial parameters, including configuring cross-domain authentication schemes according to their respective basic authentication mechanisms, and exchanging public keys between authentication servers in each domain, ultimately obtaining common system parameters. Server in Domain A private key Public key ;

[0012] Step (2), Device Anonymity Generation and Verification, Devices from Domain A Self-generated anonymity and sent to the authentication server within its domain. Send a signature request;

[0013] Authentication server Verify the validity of the anonymity and confirm the message and its legality, then store the valid anonymity in the locally maintained database;

[0014] Step (3), cross-domain authentication, when the smart device When cross-domain access to data from a device in domain B is required, it will initiate a cross-domain access request, including the device's... A cross-domain request is initiated, the edge server performs re-signing, and finally the edge server in domain B verifies it;

[0015] In this invention, the authentication server is responsible for the identity management of devices in its domain and the verification of the legality of the anonymous identity of the devices, while the edge server is responsible for cross-domain authentication. Because in the heterogeneous industrial IoT scenario, different domains adopt different authentication schemes, the introduction of proxy re-signature is used to complete the mutual authentication between heterogeneous domain devices. Furthermore, using the edge server as a proxy can reduce the cost of introducing additional third parties and prevent potential key leakage.

[0016] Step (4) Batch device cross-domain authentication, which is to complete the situation where multiple devices simultaneously initiate cross-domain authentication requests through a batch verification mechanism.

[0017] Furthermore, the detailed method for system initialization in step (1) is as follows:

[0018] Step (1.1), System parameter settings, first based on security parameters In this case, the system generates a set of globally shared parameters; then it determines the bilinear mapping pairings. ,in , All are prime numbers Cyclic group of order, selection generator , generator Preset public hash function , , and ;

[0019] Then the common system parameters are obtained. It will be shared across domains;

[0020] Step (1.2): Servers in different heterogeneous domains generate public-private key pairs, where the authentication server... Randomly generate private key Simultaneously calculate the corresponding public key. To achieve secure access without additional key negotiation, the public key is then... Published to the blockchain for sharing with other servers;

[0021] Step (1.3): To ensure that cross-domain authentication and communication are not limited by the original configurations of each domain, each domain must share its authentication scheme and cryptographic algorithm during the system initialization phase. (For example: Domain B uses the IBC authentication scheme; Domain B shares its signature algorithm...) and encryption / decryption algorithms Published to the blockchain, enabling other domains to reference relevant information in cross-domain interactions.

[0022] Furthermore, the specific process of device anonymity generation and verification in step (2) is as follows:

[0023] Step (2.1), Equipment The specific process for generating a long-term public-private key pair is as follows:

[0024] First, the authentication server Verify the validity of the certificate. If the certificate is valid, calculate and randomly select In this step, domain A Use the public key of the CA that issued the certificate to verify the device. Certificate held The system checks the digital signature of the certificate, as well as its validity period, whether it has been revoked (by querying the Certificate Revocation List, CRL), and whether the identity information in the certificate complies with the policy. Only if all of these conditions are met is the certificate considered valid.

[0025] Then, the authentication server calculate , And based on the cryptographic algorithm used in domain B... Generate random key pairs , It is by For equipment The generated partial public key; Depend on For equipment The generated partial private key;

[0026] via secure channel Send to device ,equipment Then its long-term key pair is generated. and long-term public keys ; , It is equipment The initial public-private key pair;

[0027] Step (2.2), Equipment Generate your own temporary anonymity The specific process is as follows:

[0028] equipment calculate ,in It is a temporary anonymous private key; device calculate , ,in Current timestamp; device Calculate signature ,in ; It is a signature The second part, that is, ,in , Finally, the equipment Message Send to .

[0029] Step (2.3), Authentication Server Received device Message signature sent Then, first check the timestamp. The validity of the timestamp is checked. If the timestamp is invalid, the message is discarded; if it is valid, signature verification continues. The specific process is as follows:

[0030] calculate , and Then, verify the following equation. If the above equation holds true, then... Store to the local database; if not, terminate the request.

[0031] Since this invention targets device authentication in heterogeneous domains, that is, device authentication between industrial domains using different authentication schemes, in order to complete cross-domain authentication more efficiently, a proxy re-signature technology is introduced. While keeping the authentication scheme of this domain unchanged, the edge server acts as a proxy to complete the cross-domain authentication of devices, and can complete the cross-domain authentication of batch devices. The specific process of cross-domain authentication in step (3) is as follows:

[0032] Step (3.1), Equipment To generate a cross-domain request signature, the device must first... Calculate signature ,in , ,and , This is the current timestamp; subsequently, Calculation generation , Generate proof , ;in, All are used to assist in verifying the authenticity of device anonymity; finally, Message Send to the edge server of domain A ;

[0033] Step (3.2), when Received from device News Afterwards, an inspection will be conducted. The validity of the message is checked to determine if it has expired; if valid, the system then checks the local database for the existence of the anonymous identifier. The specific process is as follows:

[0034] Signature check by verifying the following formula If verification fails, the request will be terminated. Generate resigned key ; This represents the initial public key of the edge server; It is equipment Generated temporary anonymous private key; edge server Get resigned ,in If this step fails, the request is terminated.

[0035] final, Message Send to .

[0036] Step (3.3) To verify message validity, the edge server first... By checking the timestamp This verifies the freshness and validity of the message. If the verification passes, the equation is then further verified. Is it true? If it is true, then... calculate ,verify Subsequently, Signature message Send to Verify the signature and... Stored in a local database, where This is the expiration time for the anonymous information, used to prevent authenticated devices from frequently accessing resources within the domain;

[0037] Step (3.4): After completing the above authentication, the subsequent access process is as follows:

[0038] equipment Ready to access devices in domain B and send a message to it , Use its private key Regarding the message Sign it and get This process is based on the cryptographic algorithm used in domain B. Then the device... To the equipment send: ;

[0039] According to the received Query the corresponding database And perform signature verification; if the signature is valid, use Encrypt the data and return it to Subsequently, Use private key Decryption will retrieve the data. After completing the above process, the two different domains... and This enables lightweight anonymous authentication and data exchange.

[0040] Furthermore, the specific process of batch device cross-domain authentication in step (4) is as follows:

[0041] Step (4.1), Edge Server in Domain A take over Messages from individual devices First, check if the message has expired; if the message is invalid, discard it; if the message is valid, query the local database to determine the anonymity identifier. Does it exist?

[0042] Step (4.2), Edge Server The process of sending messages from multiple devices is as follows:

[0043] First, calculate the resignature key. And perform resigning to obtain ; Calculate aggregate signature ,in , ;final, send For the edge server in domain B ;

[0044] Step (4.3), Edge Server in Domain B First, verify that the timestamp of each message is valid; if valid, then calculate... Come to check Is it correct? Then Verify the equation Does it hold true? If the equation holds true, That is, successfully certify multiple devices and request Store in its local database The system sets the validity period for anonymous information. If the equation is not true, it determines that there is a device authentication failure in the batch. If the batch verification fails, a binary search rollback method is used to divide the batch into two parts for verification. The range of the fault subset is narrowed down by recursion to locate invalid messages. This method reduces the detection overhead to rounds in sparse fault scenarios and avoids the situation of discarding the entire batch due to a single fault.

[0045] Beneficial effects: This invention uses certificate-free cryptography to generate anonymous identities and introduces a dynamic anonymous identity update mechanism to ensure secure authentication and privacy protection for devices. Furthermore, a batch authentication strategy is introduced to reduce communication overhead and improve authentication efficiency. Compared with existing technologies, this invention has the following advantages:

[0046] (1) To improve the flexibility and efficiency of authentication between heterogeneous domains, this invention uses proxy resigning to support cross-domain authentication and batch verification of multiple devices. The edge server can directly generate resigning keys without relying on any additional third parties, thereby effectively reducing the risk of private key leakage.

[0047] (2) In order to protect device privacy and prevent long-term tracking, the present invention utilizes a certificateless cryptographic system and introduces a dynamic anonymous identity mechanism, enabling each device to update its temporary pseudonym autonomously and periodically, thereby achieving non-associativity in cross-domain authentication without relying on a trusted third party.

[0048] (3) The present invention employs formal correctness and security analysis. The analysis results show that the present invention guarantees privacy, integrity, resistance to external attacks and transparency. The present invention provides more functions while maintaining similar overhead. Attached Figure Description

[0049] Figure 1 is a system model diagram of the present invention;

[0050] Figure 2 is an overall flowchart of the present invention;

[0051] Figure 3 shows the experimental equipment of the present invention;

[0052] Figure 4 shows the computational overhead of different entities in this invention;

[0053] Figure 5 shows the computational overhead of the present invention under different numbers of devices;

[0054] Figure 6 is a graph showing the computational overhead of the multi-device batch cross-domain authentication processing time of the present invention. Detailed Implementation

[0055] The technical solution of the present invention will be described in detail below, but the scope of protection of the present invention is not limited to the embodiments described.

[0056] Existing cross-heterogeneous domain authentication methods for the Industrial Internet of Things (IIoT) typically have limitations in processing power and data transmission efficiency, and lack an effective mechanism for flexibly updating anonymous identities. This makes them unable to meet the demand for efficient, anonymous, and secure authentication in complex industrial environments. As shown in Figure 1, the present invention proposes a cross-heterogeneous domain authentication method based on proxy re-signature for the IIoT. Domain A uses a PKI authentication scheme, while domain B uses an IBC authentication scheme. The system model consists of four core entities: authentication servers, edge servers, devices, and a blockchain. The blockchain serves as a trusted platform jointly established by authentication servers and edge servers from multiple industrial domains. It maintains a public ledger and forms a consortium blockchain. The blockchain operates as a consortium blockchain jointly maintained by all domains, rather than building a separate blockchain for each domain. Its purpose is to build cross-domain trust and record shared authentication information. Servers in each industrial domain share the authentication algorithms they employ and ensure information security during transmission. To achieve collaborative product manufacturing, devices in domain A must complete identity authentication through the edge server in domain B.

[0057] In this invention, the primary responsibility of the authentication server is to store anonymous identities for devices, without directly participating in the cross-domain authentication process, thus effectively reducing computational overhead. The edge server, possessing strong computing and storage capabilities, participates in the cross-domain authentication of smart devices. The edge server acts as both agent and proxied party, responsible for re-signing and verifying the converted signature. This design alleviates the burden on the authentication server and avoids the need for an additional third party as a proxy. In different industrial domains, the device, as a smart terminal, is responsible for initiating cross-domain authentication requests. The device carries a unique and legitimate identity and is equipped with valid information for authentication.

[0058] As shown in Figure 1, the cross-heterogeneous domain authentication method based on proxy re-signature in the Industrial Internet of Things of the present invention includes the following steps:

[0059] Step (1): System initialization. Participating industrial domains negotiate several initial parameters, including configuring cross-domain authentication schemes according to their respective basic authentication mechanisms, and exchanging public keys between authentication servers in each domain, ultimately obtaining common system parameters. Server in Domain A private key Public key ;

[0060] Step (2), Device Anonymity Generation and Verification, Devices from Domain A Self-generated anonymity and sent to the authentication server within its domain. Send a signature request;

[0061] Authentication server Verify the validity of the anonymity and confirm the message and its legality, then store the valid anonymity in the locally maintained database;

[0062] Step (3), cross-domain authentication, when the smart device When cross-domain access to data from a device in domain B is required, it will initiate a cross-domain access request, including the device's... A cross-domain request is initiated, the edge server performs re-signing, and finally the edge server in domain B verifies it;

[0063] In this invention, the authentication server is responsible for the identity management of devices in its domain and the verification of the legality of the anonymous identity of the devices, while the edge server is responsible for cross-domain authentication. Because in the heterogeneous industrial IoT scenario, different domains adopt different authentication schemes, the introduction of proxy re-signature is used to complete the mutual authentication between heterogeneous domain devices. Furthermore, using the edge server as a proxy can reduce the cost of introducing additional third parties and prevent potential key leakage.

[0064] Step (4) Batch device cross-domain authentication, which is to complete the situation where multiple devices simultaneously initiate cross-domain authentication requests through a batch verification mechanism.

[0065] The detailed method for system initialization in step (1) of this embodiment is as follows:

[0066] Step (1.1), System parameter settings, first based on security parameters In this case, the system generates a set of globally shared parameters; then it determines the bilinear mapping pairings. ,in , All are prime numbers Cyclic group of order, selection generator , generator Preset public hash function , , and ;

[0067] Then the common system parameters are obtained. It will be shared across domains;

[0068] Step (1.2): Servers in different heterogeneous domains generate public-private key pairs, where the authentication server... Randomly generate private key Simultaneously calculate the corresponding public key. To achieve secure access without additional key negotiation, the public key is then... Published to the blockchain for sharing with other servers;

[0069] Step (1.3): To ensure that cross-domain authentication and communication are not limited by the original configurations of each domain, each domain must share its authentication scheme and cryptographic algorithm during the system initialization phase. (For example: Domain B uses the IBC authentication scheme; Domain B shares its signature algorithm...) and encryption / decryption algorithms Published to the blockchain, enabling other domains to reference relevant information in cross-domain interactions.

[0070] The specific process of device anonymization generation and verification in step (2) of this embodiment is as follows:

[0071] Step (2.1), Equipment The specific process for generating a long-term public-private key pair is as follows:

[0072] First, the authentication server Verify the validity of the certificate. If the certificate is valid, calculate and randomly select In domain A The public key of the CA that issued the certificate will be used to verify the device. Certificate held The digital signature is checked, and the certificate is verified to be valid only if it is valid. It also checks the certificate's validity period, whether it has been revoked (by querying the Certificate Revocation List, CRL), and whether the identity information in the certificate complies with the policy.

[0073] Then, the authentication server calculate , And based on the cryptographic algorithm used in domain B... Generate random key pairs , It is by For equipment The generated partial public key; Depend on For equipment The generated partial private key;

[0074] via secure channel Send to device ,equipment Then its long-term key pair is generated. and long-term public keys ; , It is equipment The initial public-private key pair;

[0075] Step (2.2), Equipment Generate your own temporary anonymity The specific process is as follows:

[0076] equipment calculate ,in It is a temporary anonymous private key; device calculate , ,in Current timestamp; device Calculate signature ,in ; It is a signature The second part, that is, ,in , Finally, the equipment Message Send to .

[0077] Step (2.3), Authentication Server Received device Message signature sent Then, first check the timestamp. The validity of the timestamp is checked. If the timestamp is invalid, the message is discarded; if it is valid, signature verification continues. The specific process is as follows:

[0078] calculate , and Then, verify the following equation. If the above equation holds true, then... Store to the local database; if not, terminate the request.

[0079] Since this invention targets device authentication in heterogeneous domains, that is, device authentication between industrial domains using different authentication schemes, in order to complete cross-domain authentication more efficiently, a proxy re-signature technology is introduced. While keeping the authentication scheme of this domain unchanged, the edge server acts as a proxy to complete the cross-domain authentication of devices, and can complete the cross-domain authentication of batch devices. The specific process of cross-domain authentication in step (3) is as follows:

[0080] Step (3.1), Equipment To generate a cross-domain request signature, the device must first... Calculate signature ,in , ,and , This is the current timestamp; subsequently, Calculation generation , Generate proof , ;in, All are used to assist in verifying the authenticity of device anonymity; finally, Message Send to the edge server of domain A ;

[0081] Step (3.2), when Received from device News Afterwards, an inspection will be conducted. The validity of the message is checked to determine if it has expired; if valid, the system then checks the local database for the existence of the anonymous identifier. The specific process is as follows:

[0082] Signature check by verifying the following formula If verification fails, the request will be terminated. Generate resigned key ; This represents the initial public key of the edge server; It is equipment Generated temporary anonymous private key; edge server Get resigned ,in If this step fails, the request is terminated.

[0083] final, Message Send to .

[0084] Step (3.3) To verify message validity, the edge server first... By checking the timestamp This verifies the freshness and validity of the message. If the verification passes, the equation is then further verified. Is it true? If it is true, then... calculate ,verify Subsequently, Signature message Send to Verify the signature and... Stored in a local database, where This is the expiration time for the anonymous information, used to prevent authenticated devices from frequently accessing resources within the domain;

[0085] Step (3.4): After completing the above authentication, the subsequent access process is as follows:

[0086] equipment Ready to access devices in domain B and send a message to it , Use its private key Regarding the message Sign it and get This process is based on the cryptographic algorithm used in domain B. Then the device... To the equipment send: ;

[0087] According to the received Query the corresponding database And perform signature verification; if the signature is valid, use Encrypt the data and return it to Subsequently, Use private key The data can be obtained by decryption. After completing the above process, and This enables lightweight anonymous authentication and data exchange.

[0088] The specific process of step (4) of batch device cross-domain authentication in this embodiment is as follows:

[0089] Step (4.1), Edge Server in Domain A take over Messages from individual devices First, check if the message has expired; if the message is invalid, discard it; if the message is valid, query the local database to determine the anonymity identifier. Does it exist?

[0090] Step (4.2), Edge Server The process of sending messages from multiple devices is as follows:

[0091] First, calculate the resignature key. And perform resigning to obtain ; Calculate aggregate signature ,in , ;final, send For the edge server in domain B ;

[0092] Step (4.3), Edge Server in Domain B First, verify that the timestamp of each message is valid; if valid, then calculate... Come to check Is it correct? Then Verify the equation Does it hold true? If the equation holds true, That is, successfully certify multiple devices and request Store in its local database The system sets the validity period for anonymous information. If the equation is not true, it determines that there is a device authentication failure in the batch. If the batch verification fails, a binary search rollback method is used to divide the batch into two parts for verification. The range of the fault subset is narrowed down by recursion to locate invalid messages. This method reduces the detection overhead to rounds in sparse fault scenarios and avoids the situation of discarding the entire batch due to a single fault.

[0093] To facilitate understanding of the technical solution in this embodiment, the meanings of the relevant variables are explained in Table 1.

[0094] Table 1

[0095] This embodiment uses the MIRACLCORE cryptographic library to obtain the execution time of basic cryptographic operations. Device-related operations are performed on a Raspberry Pi 4B+ device. Edge server operations are performed on a desktop computer equipped with an Intel(R) Core(TM) i7-10700 CPU (2.90GHz), 16GB RAM, and running Ubuntu 20.04.6 to simulate the device's computing environment. The evaluated operations include hashing, encryption, and signature algorithms. In the MIRACLCORE cryptographic library, a symmetric bilinear pairing based on the BLS123-81 pairwise curve is used. Its security level is 128 bits.

[0096] This embodiment evaluates the processing overhead of each entity throughout the entire process, from system initialization to the communication phase, covering all critical operations. Specifically, the device... Responsible for generating its anonymous identity and initiating cross-domain requests; edge server Responsible for verifying from The request is made and a re-signature operation is performed; Receive from The signature is then forwarded to the corresponding target device, and the device subsequently... Verify the signature and return the requested data. As shown in Figure 3, the total computation time for the four types of core entities in actual execution is as follows: Device The time was 22.433ms for the edge server. The latency was 29.362ms for the edge server. The time was 41.817ms, for the device. The execution time is 22.684ms. Analysis of the execution time of each entity shows that the proposed solution has low overall computational overhead and is suitable for resource-constrained equipment environments.

[0097] Similarly, this invention statistically analyzed the computational overhead of the preparation and authentication phases, as shown in Figure 3. In the cross-domain authentication phase, virtual simulation experiments were conducted with 1 to 50 concurrent device requests, and the performance in a batch device authentication request scenario was evaluated, as shown in Figure 4.

[0098] To improve authentication efficiency in multi-device scenarios, this invention introduces a batch authentication mechanism based on re-signature, using an edge server. Perform cross-domain anonymization processing on multiple devices, aggregate their re-signature results, and send the aggregated signature to [the appropriate domain]. A unified verification was performed, and the results are shown in Figure 5.

[0099] Experimental results show that the computational overhead of the method of the present invention is very lightweight, which has significant advantages over existing methods.

[0100] In summary, this invention is applicable to cross-domain authentication scenarios in the Industrial Internet of Things (IIoT), improving the authentication problem for IoT devices in heterogeneous domains. To protect device privacy and provide flexibility in anonymity, it employs certificate-free cryptography to generate anonymous identities and introduces a dynamic anonymous identity update mechanism to ensure secure authentication and privacy protection. Cross-domain authentication of IoT devices in heterogeneous domains is achieved through proxy re-signature technology. Compared to existing proxy re-signature schemes, this invention uses an edge server as a proxy, reducing the cost of introducing third-party proxies and avoiding potential security issues. Furthermore, a batch authentication strategy is introduced to reduce communication overhead and improve authentication efficiency.

Claims

1. A cross-heterogeneous domain authentication method based on proxy re-signature for application in the Industrial Internet of Things, characterized in that, Includes the following steps: Step (1) System initialization: The participating industrial domains negotiate the corresponding initial parameters, configure the cross-domain authentication scheme, and exchange public keys between the authentication servers in each domain, ultimately obtaining the public system parameters and the server in domain A. private key Public key Step (2), Device Anonymity Generation and Verification, Devices from Domain A Self-generated anonymity and sent to the authentication server within its domain. Send a signature request; authentication server Verify the validity of the anonymity and confirm the message and the legality of the confirmation message, and then store the valid anonymity in the locally maintained database; Step (3), cross-domain authentication, when the smart device of domain A When cross-domain access is required to request corresponding data from a device in domain B, the device A cross-domain access request will be initiated, including for the device. Initiate a cross-domain request, the edge server performs re-signing, and finally the edge server in domain B performs verification; Step (4) Batch device cross-domain authentication, that is, to complete the simultaneous initiation of cross-domain authentication requests by multiple devices through a batch verification mechanism.

2. The cross-heterogeneous domain authentication method based on proxy re-signature in the Industrial Internet of Things as described in claim 1, characterized in that: The detailed method for system initialization in step (1) is as follows: Step (1.1), system parameter setting, first based on security parameters In this case, the system generates a set of globally shared parameters; then it determines the bilinear mapping pairings. ,in , All are prime numbers Cyclic group of order, selection generator ， generator ； Preset public hash function ， ， and ; and then obtain the common system parameters. This will be shared across domains; Step (1.2): Servers in different heterogeneous domains generate public-private key pairs, where the authentication server... Randomly generate private key Simultaneously calculate the corresponding public key. To achieve secure access without additional key negotiation, the public key is then... Publish to the blockchain for other servers to share; Step (1.3): To ensure that cross-domain authentication and communication are not limited by the original configuration of each domain, each domain shares the authentication scheme and cryptographic algorithm it adopts.

3. The cross-heterogeneous domain authentication method based on proxy re-signature in the Industrial Internet of Things according to claim 1, the specific process of device anonymity generation and verification in step (2) is as follows: Step (2.1), device The process of generating a long-term public-private key pair is as follows: First, the authentication server... Verify the validity of the certificate. If the certificate is valid, calculate and randomly select Then, the authentication server calculate ， And based on the cryptographic algorithm used in domain B... Generate random key pairs ， It is by For equipment The generated partial public key; It refers to the For equipment The generated partial private key; via secure channel Send to device ,equipment Then its long-term key pair is generated. and long-term public keys ； 、 It is equipment The initial public / private key pair; step (2.2), device Generate your own temporary anonymity The specific process is as follows: Equipment calculate ,in It is a temporary anonymous private key; device calculate ， ,in This is the current timestamp; equipment Calculate signature ,in ； It is a signature The weight; finally, the equipment Message Send to ； Step (2.3), Authentication Server Received device Message signature sent Then, first check the timestamp. The validity of the timestamp is checked. If the timestamp is invalid, the message is discarded; if it is valid, signature verification continues. The specific process is as follows: calculate ， and ； Then, verify the following equation If the above equation holds true, then... Store to the local database; if not, terminate the request.

4. The cross-heterogeneous domain authentication method based on proxy re-signature in the Industrial Internet of Things according to claim 1, the specific process of cross-domain authentication in step (3) is as follows: Step (3.1), device To generate a cross-domain request signature, the device must first... Calculate signature ,in ， ,and ， This is the current timestamp; subsequently, Calculation generation ， Generate proof ， ;in, All are used to assist in verifying the authenticity of device anonymity; finally, Message Send to the edge server of domain A ； Step (3.2), when Received from device News Afterwards, an inspection will be conducted. The validity of the message is checked to determine if it has expired; if valid, the system then checks the local database for the existence of the anonymous identifier. The specific process is as follows: Signature check by verifying the following formula If verification fails, the request will be terminated. Generate resigned key ； This represents the initial public key of the edge server; It is equipment Generated temporary anonymous private key; edge server Get resigned ,in If this step fails, the request is terminated; ultimately, Message Send to 。 5. Step (3.3) To verify message validity, the edge server first... By checking the timestamp This verifies the freshness and validity of the message. If the verification passes, the equation is then further verified. Is it true? If it is true, then... calculate ,verify Subsequently, Signature message Send to Verify the signature and... Stored in a local database, where The expiration time for this anonymous information is used to prevent authenticated devices from frequently accessing resources within the domain; Step (3.4), after completing the above authentication, the subsequent specific access process is as follows: Device Ready to access devices in domain B and send a message to it ， Use its private key Regarding the message Sign it and get This process is based on the cryptographic algorithm used in domain B. Then the device... To the equipment send: According to the received Query the corresponding database And perform signature verification; if the signature is valid, use Encrypt the data and return it to Subsequently, Use private key The data can be obtained by decryption.

6. The cross-heterogeneous domain authentication method based on proxy re-signature in industrial IoT according to claim 1, the specific process of step (4) batch device cross-domain authentication is as follows: Step (4.1), edge server in domain A take over Messages from individual devices First, check if the message has expired; if the message is invalid, discard it; if the message is valid, query the local database to determine the anonymity identifier. Does it exist; Step (4.2), Edge Server Sending messages from multiple devices involves the following process: First, calculating the resignature key. And perform resigning to obtain ； Calculate aggregate signature ,in ， ;final, send For the edge server in domain B ； Step (4.3), Edge Server in Domain B First, verify that the timestamp of each message is valid; if valid, then calculate... Come to check Is it correct? Then Verify the equation Does it hold true? If the equation holds true, That is, successfully certify multiple devices and request Store in its local database The validity period of anonymous information is set; if the equation is not true, it is determined that there is a device authentication failure in the batch. If the batch verification fails, the batch will be divided into two parts for verification using a binary search backoff method.

Images