Lightweight industrial Internet of Things cross-domain authentication method and system based on block chain

Abstract

The invention discloses a lightweight industrial Internet of Things cross-domain authentication method and system based on a block chain, and the method comprises the steps: an initialization stage: defining system parameters through a trusted mechanism, the system parameters including a hash function, a symmetric encryption / decryption algorithm, a large prime number and parameters for Chebyshev polynomial calculation; the registration stage comprises user registration, edge node registration and trusted mechanism registration; and a cross-domain authentication stage: initiating an authentication request based on a user, after the authentication request is verified by a local trusted mechanism, querying a global Merkel tree root through a block chain to complete cross-domain identity verification, and negotiating a session key based on Chebyshev mapping. According to the invention, the security and reliability of cross-domain authentication are effectively improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of information and network security, and particularly relates to a lightweight industrial Internet of Things cross-domain authentication method and system based on a block chain. BACKGROUND

[0002] Industrial Internet of Things (IIoT) is a new paradigm of deep integration of Internet of Things technology and industrial scenarios. Through the integration of information communication technology and industrial operation technology, it realizes the global interconnection of industrial sensors, intelligent devices, production systems and user endpoints. Its core value lies in breaking the information silos in traditional industrial environments, improving the efficiency, controllability and productivity of manufacturing processes, and has become a key supporting technology for promoting industrial digital transformation. In typical scenarios such as intelligent manufacturing, logistics tracking and remote operation and maintenance of equipment, IIoT continuously reshapes industrial production patterns by optimizing sensor data collection, machine coordination control and production process scheduling.

[0003] In a typical production line management system, multiple types of sensors deployed on the production line collect real-time device operating parameters, environmental status and other key data, and aggregate the information to the application server for storage and analysis. The production line administrator realizes real-time monitoring and abnormal scheduling of the device operating status by accessing the server data. In this process, secure and trusted communication and identity authentication are the core prerequisites for reliable system operation: on the one hand, access rights need to be strictly controlled to ensure that only authorized users can access specified production line data and prevent unauthorized information leakage; on the other hand, a cross-domain trust mechanism needs to be established in cross-domain collaboration scenarios to ensure the confidentiality and integrity of data transmission. However, with the increasing complexity of manufacturing, a single domain has been difficult to complete the entire production process, and multi-domain collaboration has become an inevitable trend in modern manufacturing. Although IIoT technology provides technical support for cross-domain device collaboration, it also introduces multiple security challenges, including: Device security risks: IIoT devices deployed in open industrial environments are vulnerable to physical tampering, identity cloning and malicious impersonation attacks, directly threatening the trustworthiness of the data source.

[0004] Channel security risks: Public communication channels carrying sensitive production data are vulnerable to passive listening, data tampering and other attacks, making it difficult to guarantee confidentiality and integrity.

[0005] Inter-domain trust loss: Each domain is cautious about sharing private data, and lacks a natural cross-domain trust foundation, resulting in an increase in the difficulty of identity authentication and permission control when devices collaborate.

[0006] To solve the cross-domain trust problem, in recent years, many studies have tried to introduce the decentralized and tamper-proof characteristics of blockchain to build a trust mechanism. However, these schemes have exposed core contradictions with IIoT scenarios in practice, and urgently need to break through three key bottlenecks: (1) Privacy and confidentiality leakage: Many existing schemes often store sensitive data such as device identity, public key, etc. in plaintext form in the blockchain, directly exposing core information; at the same time, the public ledger feature of the blockchain makes user operations traceable, and it is difficult to achieve behavior unlinkability. This has prompted subsequent research to begin to explore privacy protection mechanisms.

[0007] (2) High resource overhead: IIoT devices are generally limited by computing, storage and energy resources, but existing schemes often require devices to interact with the blockchain frequently (such as multiple on-chain data reading), and the blockchain encryption verification operation has high computational cost, far exceeding the carrying capacity of the device, which contradicts the industry's demand for high efficiency and lightweight.

[0008] (3) DDoS attack vulnerability: Most protocols use a process design of "reading blockchain credentials first and then verifying entity identity", and attackers can easily paralyze services by launching massive fake on-chain requests to exhaust server resources, a key risk that is often overlooked in existing research.

[0009] Therefore, how to further optimize the comprehensive performance (computing, communication, storage) of the protocol while ensuring strong security, balance anonymity and traceability, and enhance resistance to future threats such as quantum computing, is still a direction worthy of in-depth research in this field. SUMMARY

[0010] To solve the technical problems existing in the prior art, the present application provides a lightweight industrial Internet of Things cross-domain authentication method and system based on blockchain, which builds a hybrid trust framework and uses Chebyshev mapping to achieve efficient key agreement without a public key infrastructure (PKI).

[0011] On the one hand, to achieve the above-mentioned purpose, the present application provides a lightweight industrial Internet of Things cross-domain authentication method based on blockchain, comprising: Initialization phase: define system parameters through a trusted agency, wherein the system parameters include a hash function, a symmetric encryption / decryption algorithm, a large prime number, and parameters for Chebyshev polynomial calculation; Registration phase: including user registration, edge node registration and trusted agency registration; Cross-domain authentication phase: based on the user's initiation of an authentication request, after verification by the local trusted agency, the global Merkle tree root is queried through the blockchain to complete cross-domain identity authentication, and the session key is negotiated based on the Chebyshev mapping.

[0012] Preferably, in the initialization phase, the parameter of the Chebyshev polynomial calculation defined by the trusted agency is used to generate the public key of the edge server.

[0013] Preferably, the user registration comprises: Based on the user equipment input identity, password, generate random number, calculate pseudo identity and pseudo password hash, and send the encrypted registration request to the trusted agency; The trusted agency generates key parameters and returns, and the user generates key and auxiliary data using biometric features, and finally stores the local verification parameters.

[0014] Preferably, the stored local verification parameters include auxiliary data generated by the fuzzy extractor, secret key, and encrypted secret parameters and authentication code.

[0015] Preferably, the edge node registration comprises: The trusted agency generates public key and private key based on Chebyshev chaotic mapping for the edge server, and distributes key material, and the edge server stores the key material for subsequent authentication and communication.

[0016] Preferably, the trusted agency registration comprises: Each trusted agency exchanges user and device information with each other, and generates a cross-domain authentication key; Each trusted agency calculates the hash value of the local data, constructs a global Merkle tree, and submits the tree root to the blockchain through a smart contract; Each trusted agency locally saves the Merkle path for subsequent verification.

[0017] Preferably, the cross-domain authentication phase comprises: The user inputs identity, password and biometric features, and generates an authentication message after local verification and sends it to the local trusted agency; After the local trusted agency verifies the freshness of the message, the user's identity information is recovered, and the global Merkle tree root on the blockchain is queried for verification; After verification, the local trusted agency and the target domain trusted agency perform key negotiation, and finally establish a shared session key between the users.

[0018] Preferably, the key negotiation adopts Chebyshev chaotic mapping to calculate the temporary session key.

[0019] Preferably, the global Merkle tree root is the authentication data stored on the blockchain, and the on-chain storage overhead is constant level.

[0020] In another aspect, in order to achieve the above-mentioned purpose, the application also provides a lightweight industrial Internet of Things cross-domain authentication system based on blockchain, comprising: Initialization module: used to define system parameters by a trusted agency, wherein the system parameters include a hash function, a symmetric encryption / decryption algorithm, a large prime number and parameters for Chebyshev polynomial calculation; Registration module: used for user registration, edge node registration and trusted agency registration; Cross-domain authentication module: used for initiating an authentication request by a user, verifying via a local trusted agency, completing cross-domain identity verification by querying a global Merkle tree root through a blockchain, and negotiating a session key based on a Chebyshev mapping; The registration module comprises: User / device: used for initiating an authentication request and performing local verification; Edge server: used for receiving and processing sensor data and participating in an authentication process; Trusted agency: used for being responsible for user and device registration, key management, Merkle tree construction and cross-domain authentication coordination; Blockchain: used for storing a global Merkle tree root and realizing updating and verification of the tree root through a smart contract.

[0021] Compared with the prior art, the present application has the following advantages and technical effects: (1) At the architecture optimization level, the present application adopts a dual mechanism of "computing power offloading + process remodeling": the computing-intensive blockchain operations (such as on-chain data reading and hash verification) are transferred from resource-limited devices to domain servers with stronger computing power, reducing the burden on the terminal; at the same time, the authentication process is remodeled, the domain server verifies the request legitimacy before responding to the blockchain interaction, intercepts malicious requests from the source through the first verification and then access mechanism, and resists DDoS attacks.

[0022] (2) At the privacy protection level, the present application innovatively designs a "hash + Merkle tree" on-chain storage mode: each domain server only exchanges the hash digest of local data, rather than the original sensitive information; the hash values of all domains are cooperatively constructed into a Merkle tree, only the globally unique Merkle tree root (short hash value) is uploaded to the blockchain, and each domain locally retains the Merkle path required for data verification. This design not only avoids uploading sensitive data to the chain, ensuring confidentiality and anonymity, but also realizes efficient verification of cross-domain data through the on-chain tree root and the local path. BRIEF DESCRIPTION OF DRAWINGS

[0023] The accompanying drawings, which form a part of this application, are included to provide a further understanding of the application and are incorporated in and constitute a part of this application. The embodiments of this application and their description together with the drawings serve to explain the application. In the drawings: Figure 1 It is a registration stage diagram of the embodiment of the present application; Figure 2 It is a first schematic diagram of the cross-domain authentication stage of the embodiment of the present application; Figure 3 This is a second schematic diagram of the cross-domain authentication stage according to an embodiment of the present invention; Figure 4 This is a schematic diagram of a lightweight industrial IoT cross-domain authentication system based on blockchain, according to an embodiment of the present invention. Detailed Implementation

[0024] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0025] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0026] In today's highly complex industrial manufacturing environment, traditional single production lines or isolated departments can no longer meet the demands of large-scale, high-efficiency production. Modern industrial systems are gradually evolving towards a multi-domain collaborative model, in which multiple independent automated production line systems ("domains") work together to complete complex manufacturing processes.

[0027] Imagine a scenario where "Domain A," responsible for precision component manufacturing, needs to collaborate closely with "Domain B," responsible for final product assembly. Superficially, the two production lines operate independently, but their efficiency and output are highly dependent on each other. Domain B's administrator must dynamically adjust its work mode and pace based on Domain A's real-time production progress and component quality data; while Domain A also needs to understand Domain B's assembly requirements in a timely manner to optimize its processing parameters and reduce production bottlenecks. To achieve this real-time, precise cross-domain collaboration, a secure and reliable cross-domain communication and authentication mechanism must be established—this is precisely the initial intention behind the design of this protocol in this technical solution.

[0028] In this embodiment, each domain has multiple users who register on their respective devices to record or observe production line data. Simultaneously, multiple servers are deployed within each domain to receive data from sensors on different production lines. Initially, the system requires users and servers to register with a trusted authentication authority (TA) via the network to obtain communication permissions. The entire system is deployed on an LTE network: the backbone transmits via cable at a rate of 100 Mbps; each wireless access network segment (i.e., each domain) transmits via 4G wireless at a rate of approximately 50 Mbps; users interact with the trusted authority (TA) and the edge server (ES) interact with the TA via network connections.

[0029] To lay the groundwork for the following discussion, let's first introduce blockchain operations. This embodiment employs a combined "on-chain notarization + off-chain verification" model to achieve cross-domain authentication and uses blockchain to achieve decentralized governance, ensuring data security and trustworthiness. First, deployment and initialization are completed on the consortium blockchain: the initiator deploys a smart contract on the Ganache blockchain and sets key parameters (such as requiredVotes=4) to ensure that in the consortium consisting of six domain servers, any significant operation involving updating the Merkle tree root requires the consent of a majority of nodes. Subsequently, the administrator adds the Ethereum addresses of each domain to the smart contract whitelist, completing the initial member registration and governance framework setup.

[0030] During the off-chain verification phase, each trusted institution's TA server generates hash values ​​based on local data and exchanges them with each other via message queues to collect complete data. Each institution independently runs a consistent Merkle tree construction algorithm (including a unified sorting rule) to generate a final, consistent root hash value. After confirmation, the on-chain update phase begins: the domain submits a new root hash creation proposal by calling Algorithm 1 of the smart contract. Other institutions read and compare the proposal content from the on-chain database, and after confirming consistency, sequentially call Algorithm 2 to complete the voting. When the cumulative number of votes reaches or exceeds requiredVotes, the smart contract automatically triggers Algorithm 3 to update currentMerkleRoot to the new root hash, thereby achieving a trusted update.

[0031] Algorithm 1 is as follows: ProposeNewRoot(proposer, newRoot) -> proposalId Require: caller ∈ institutions 1: require newRoot != 0x0 / / It is recommended to check this to avoid ambiguity. 2: proposalCounter <- proposalCounter + 1 3: proposalId <- proposalCounter 4: proposals[proposalId].newRoot <- newRoot 5: proposals[proposalId].voteCount <- 1 6: proposals[proposalId].voters[proposer] <- true 7: emit RootProposalCreated(proposalId, newRoot, proposer) 8: return proposalId Algorithm 2 is as follows: VoteForProposal(voter, proposalId) Require: caller ∈ institutions 1: proposal <- proposals[proposalId] 2: require proposal.newRoot != 0x0 3: require proposal.executed == false 4: require proposal.voters[voter] == false 5: proposal.voters[voter] <- true 6: proposal.voteCount <- proposal.voteCount + 1 7: emit ProposalVoted(proposalId, voter) 8: if proposal.voteCount >= requiredVotes then 9: ExecuteProposal(proposalId) 10: end if Algorithm 3 is as follows: Procedure ExecuteProposal(proposalId) 1: proposal <- proposals[proposalId] 2: if proposal.executed == true then 3: return 4: end if 5: currentMerkleRoot <- proposal.newRoot 6: proposal.executed <- true 7: emit ProposalExecuted(proposalId, proposal.newRoot) A complete cross-domain authentication process is initiated by the registered user. The user holds the ID of the device to be authenticated and sends a cross-domain authentication request to the Trusted Authority (TA) server in their own domain via an eNode. TA servers in different domains verify the identity based on the Merkle root stored on the blockchain. Upon receiving the request, the TA server first calculates the "root to be verified" using the currentMerkleRoot stored on the blockchain, the leaf nodes extracted locally, and the verification path (Proof), and compares it with the on-chain hash to complete identity verification. Then, it sends a request to the TA server in the target domain. Upon receiving the request, the TA server in the target domain searches for the corresponding user across the network, ultimately completing the cross-domain identity authentication.

[0032] This embodiment includes three stages: initialization, registration, and cross-domain authentication.

[0033] Initialization phase: System parameters are defined by a trusted institution, including hash function, symmetric encryption / decryption algorithm, large prime numbers, and parameters for Chebyshev polynomial calculation; Registration phase: includes user registration, edge node registration, and trusted institution registration; Cross-domain authentication phase: Based on the user's authentication request, after verification by a local trusted institution, cross-domain identity verification is completed by querying the global Merkel tree root through the blockchain, and the session key is negotiated based on the Chebyshev mapping.

[0034] Furthermore, during the initialization phase, the parameters of the Chebyshev polynomial computation defined by the trusted institution are used to generate the public key for the edge server.

[0035] Specifically, during the initialization phase, TA defines the hash function H() and the symmetric encryption / decryption algorithms Enc() / Dec(). It also defines a large prime number P for generating the public key and for Chebyshev polynomials.

[0036] Furthermore, the user registration includes (e.g.) Figure 1 ): Based on the user's input identity identifier and password, a random number is generated, the hash of the fake identity and fake password is calculated, and the encrypted registration request is sent to a trusted institution. A trusted institution generates and returns key parameters. Users use biometrics to generate keys and auxiliary data, and finally, the verification parameters are securely stored locally.

[0037] Specifically, including: Domain A user First, initiate a registration request. First, enter their identity information. Password Subsequently, the device generates three random numbers. , and And calculate a pseudo-identity and a fake password hash ).

[0038] Next use For two random numbers and Perform blurring to generate , and .

[0039] final, The registration request message { , , , , } Sent to a trusted organization in domain A via a public channel .

[0040] Trusted Institutions Process the request. First, generate random numbers. and Upon receiving from After receiving the message, use the received Used as the key, calculate the two encrypted values. and .also, Through calculation , To restore and store the user's secret value and Saved locally for subsequent authentication. After calculation, The parameter { , }Return to user via public channel .

[0041] Users compute and store local evidence. Received { , Afterwards, the biometric information is first processed by a fuzz extractor to generate a secret key. and publicly available auxiliary data ,Right now Then, it restored the state of being... The hash value of the generated secret parameter and Then, create a hash factor for local verification. | The hash factor is then used to encrypt and package all important secrets for secure storage. ), ), )as well as ).final, Securely store parameter sets on its device { , , , , The user registration phase is now complete.

[0042] Furthermore, the edge node registration includes: A trusted institution generates public and private keys based on Chebyshev chaotic mappings for the edge server and distributes key materials. The edge server stores these key materials for subsequent authentication and communication.

[0043] Specifically, the edge server of domain A Generate random numbers and will Transmitted to a trusted organization , After receiving the data, generate a large prime number P and a private key factor. Public keys are generated using Chebyshev polynomials. At the same time, it will be available to users who registered previously. and received Generate key Through a secure channel to the edge server Transmit { , , , , Edge server Store it after receiving it.

[0044] Furthermore, the trusted institution registration includes: Trusted organizations exchange user and device information and generate cross-domain authentication keys; Each trusted institution calculates the hash value of its local data, constructs a global Merkle tree, and uploads the tree root to the blockchain for storage via smart contracts; at the same time, each trusted institution locally stores the Merkle path for subsequent verification.

[0045] Specifically, different trusted organizations (TAs) transmit their respective information to each other. In this embodiment, domain B is taken as an example. produce Transmitted to a trusted institution via user registration. Combined with different generate , (These are the keys generated by user B for domains A and C, respectively), and each trusted authority TA calculates... (Taking the B domain as an example) the key used for symmetric encryption is calculated. For each domain, Each domain stores an entry for subsequent cross-domain authentication. Each domain calculates the hash of its stored content, and different TAs form a Merkle tree root using their hash values, which is then transmitted to the blockchain for storage. At the same time, each domain retains its own path for verification.

[0046] Furthermore, the cross-domain authentication phase includes: After the user enters their identity, password and biometrics, an authentication message is generated and sent to a trusted institution in the domain after local verification is successful. After the trusted institution in this domain verifies the freshness of the message, it restores the user's identity information and queries the global Merkle root on the blockchain for verification. After successful verification, key negotiation is conducted with trusted authorities in this domain and trusted authorities in the target domain, and a shared session key is established among end users.

[0047] Specifically, cross-domain authentication is performed by a user located in domain A. Users of Domain B Secure mutual authentication is performed, ultimately negotiating a shared session key. This process is handled by the domain A authorization server. Domain B Authorization Server And blockchain technology can assist in completing this. For example... Figure 2 , Figure 3 As shown.

[0048] (1) User Initiate an authentication request. First, enter... , And collect biological information Equipment usage auxiliary data Regeneration key ), and restore local credentials. , ,as well as Then, calculate the local authentication code. and verify Check if the stored value is equal; if not, abort.

[0049] After successful verification, the device generates a temporary random number. timestamp and the incoming target user identifier And calculate the authentication message , , as well as .

[0050] Finally, the message { , , UAM4 } is sent to its domain server ESA.

[0051] (2) Upon receiving the message, first verify the timestamp. freshness Then restore and verify If the verification passes, a portion of the shared key will be restored. and .

[0052] then, From blockchain verification Information: First, the Merkle root obtained from the smart contract is called, and the verification path is read from the local machine for verification. .

[0053] After successful verification, generate new random numbers. and timestamp Simultaneously calculate Go to database B based on key get And through the decryption function get .

[0054] Finally, the message is calculated and encrypted. and and will { , , }Sent via base station .

[0055] (3) Trusted institutions Received message { , , After that, first check the timestamp. Is it within the valid time difference ΔT? Then, it uses the key. Decrypt EAM2 to obtain and Subsequently, Mix these two values After concatenation, a hash operation is performed, and the result is verified to be equal to EAM1. If the verification passes, Select a new random number and timestamp And perform Chebyshev function operations. Generate the session key factor ssk. Finally, it calculates four new messages: ; ; ; ; The information is encrypted, and the calculation is complete. Will{ , , , , }Send to .

[0056] user Received message { , , , , After that, first check the timestamp. Its validity. Simultaneously, it relies on the biometric information provided by the user. generate and ,calculate and with the pre-stored Perform a comparison. Once the verification passes, use Perform an XOR operation on EBM3 to obtain Then, it calculates... The message integrity is verified by comparing it with EBM4. Upon successful verification... use Perform an XOR operation on EBM2 to obtain Then use The session key SK is calculated by XORing EBM1 with its own credential hash.

[0057] at last, Select a new random number and timestamp Encryption generation And calculate the message authentication code UBM2, and set {UBM1, UBM2, ... Send it out.

[0058] (4) Receive message and verify The freshness. Then, use Decrypting EBM1 yields: ; And verify .

[0059] After successful verification, calculate the temporary shared secret. Next, a timestamp is generated. And calculate the returned message Finally, the message {EAMM3, Send to user .

[0060] (5) User Received the final message, verification And EAMM2. After successful verification, it decrypts... And calculate the final session key. And judge Are they equal? ​​At this point, and Once the same session key SK is negotiated, the authentication and key negotiation process is complete.

[0061] This embodiment also provides a lightweight industrial IoT cross-domain authentication system based on blockchain, applied to a blockchain-based lightweight industrial IoT cross-domain authentication method, including (such as...) Figure 4 ): Initialization module: used to define system parameters through a trusted institution, wherein the system parameters include hash function, symmetric encryption / decryption algorithm, large prime numbers, and parameters for Chebyshev polynomial calculation; Registration module: Used for user registration, edge node registration, and trusted organization registration; Cross-domain authentication module: Used to complete cross-domain identity verification by querying the global Merkel tree root through the blockchain after the user initiates an authentication request and the verification is conducted by a local trusted institution, and the session key is negotiated based on the Chebyshev mapping; The registration module includes: User / device ): Used to initiate authentication requests and perform local verification; Edge server (ES): Used to receive and process sensor data and participate in the authentication process; Trusted Authority (TA): Responsible for user and device registration, key management, Merkle tree construction, and cross-domain authentication coordination; Blockchain (BC): Used to store the global Merkle root and to update and verify the root through smart contracts.

[0062] The following is a detailed description of the core components of the system model, in which U and TA, and ES and TA, are connected via a network. Edge Server (ES): Each edge server controls all sensors on a single production line. The information collected by the sensors is stored and primarily processed by the server for further analysis and retrieval. Information from the production line may include system parameters, output, total production cycle length, and product quantity. Before providing services, the ES (Electronic Data Center) must register with the TA (Task Force) to ensure service availability.

[0063] User / Device: It acts as a supervisor of one or more production lines, capable of accessing real-time information about the production line collected and stored by sensors on a specific server. It can access one or more specific Elasticsearch instances. Before enabling this feature, the TA should register or pre-authenticate on the system. To ensure its effectiveness.

[0064] User / Device: A UI acts as a supervisor for one or more production lines, capable of accessing real-time information collected and stored by sensors on a specific server. A particular UI can access one or more specific ESs. Before enabling this functionality, the UI should be registered or pre-authenticated on the system by the TA to ensure its validity.

[0065] Trusted Institution (TA): The TA (Transaction Provider) is used for system authentication, responsible for pre-authenticating users and application servers when they connect to the system before they run. It generates and distributes necessary confidential information, such as key materials, for each user and application server. Simultaneously, the TA generates hashes of data within its managed domains, submits these hashes to establish a Merkle Tree between different domains, and then uploads them to the blockchain storage for subsequent authentication.

[0066] Blockchain (BC): Trusted Entities (TAs) within each domain are responsible not only for user and device registration and management but are also designed as core nodes in the blockchain network. By using TA servers as blockchain nodes, it is ensured that each domain stores necessary information on the chain while completing registration, authentication, and key management, thereby achieving trusted sharing and verification across domains. Due to the decentralized, tamper-proof, and traceable characteristics of blockchain, TA nodes can collaboratively maintain a globally consistent ledger state through a consensus mechanism, effectively improving the security and reliability of cross-domain authentication.

[0067] The cross-domain authentication and key negotiation protocol proposed in this technical solution exhibits significant advantages in both security and performance. Regarding security, the protocol, through rigorous formal logic proof, demonstrates, within an enhanced security framework combining a random oracle model and a Chalcedonian adversary model, that its security is reducible to the computational difficulty of the chaotic mapping Diffie-Hellman problem, making the advantage of any probabilistic multinomial-time attacker in breaking the protocol negligible. Furthermore, the ProVerif formal verification tool verifies that the protocol satisfies security properties such as forward secrecy, cross-domain authentication, session key consistency, resistance to man-in-the-middle attacks, resistance to spoofing attacks, and non-associativity. The protocol also possesses the ability to resist multiple security threats, including privileged insider attacks, replay attacks, offline password guessing attacks, spoofing attacks, physical device loss attacks, and distributed denial-of-service attacks, and achieves perfect forward secrecy.

[0068] In terms of performance, the protocol employs lightweight cryptographic primitives such as hash functions, XOR operations, and chaotic semigroup operations, significantly reducing computational overhead. Performance evaluations show that the total overhead of this technical solution is only 17520.44 microseconds, with computational costs of 17444 microseconds and communication costs of 76.44 microseconds, both superior to existing similar solutions. In particular, the protocol compresses communication data to 3488 bits by optimizing the message structure, and through an innovative on-chain storage design, it only needs to store a 256-bit global root hash on the blockchain, achieving constant on-chain storage overhead independent of network size, demonstrating excellent scalability and practicality.

[0069] In summary, this technical solution achieves high performance while ensuring strong security, perfectly balancing the needs of security and efficiency, and is particularly suitable for large-scale IoT cross-domain authentication scenarios with limited resources.

[0070] The above are merely preferred embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A lightweight cross-domain authentication method for industrial IoT based on blockchain, characterized in that, include: Initialization phase: System parameters are defined by a trusted institution, including hash function, symmetric encryption / decryption algorithm, large prime numbers, and parameters for Chebyshev polynomial calculation; Registration phase: includes user registration, edge node registration, and trusted institution registration; Cross-domain authentication phase: Based on the user's authentication request, after verification by a local trusted institution, cross-domain identity verification is completed by querying the global Merkel tree root through the blockchain, and the session key is negotiated based on the Chebyshev mapping.

2. The lightweight industrial IoT cross-domain authentication method based on blockchain according to claim 1, characterized in that, During the initialization phase, the parameters of the Chebyshev polynomial computation defined by the trusted institution are used to generate the public key for the edge server.

3. The lightweight industrial IoT cross-domain authentication method based on blockchain according to claim 1, characterized in that, The user registration includes: Based on the user's input identity identifier and password, a random number is generated, the hash of the fake identity and fake password is calculated, and the encrypted registration request is sent to a trusted institution. A trusted institution generates and returns key parameters. Users use biometrics to generate keys and auxiliary data, and finally, the verification parameters are securely stored locally.

4. The lightweight industrial IoT cross-domain authentication method based on blockchain according to claim 3, characterized in that, The stored local verification parameters include auxiliary data generated by the fuzz extractor, the secret key, and the encrypted secret parameters and authentication code.

5. The lightweight industrial IoT cross-domain authentication method based on blockchain according to claim 1, characterized in that, The edge node registration includes: A trusted institution generates public and private keys based on Chebyshev chaotic mappings for the edge server and distributes key materials. The edge server stores these key materials for subsequent authentication and communication.

6. The lightweight industrial IoT cross-domain authentication method based on blockchain according to claim 1, characterized in that, The trusted organization registration includes: Trusted organizations exchange user and device information and generate cross-domain authentication keys; Each trusted institution calculates the hash value of its local data, constructs a global Merkle tree, and submits the tree root to the blockchain via a smart contract; Each trusted institution stores the Merkel path locally for subsequent verification.

7. The lightweight industrial IoT cross-domain authentication method based on blockchain according to claim 1, characterized in that, The cross-domain authentication phase includes: After the user enters their identity, password and biometrics, an authentication message is generated and sent to a trusted institution in the domain after local verification is successful. After the trusted institution in this domain verifies the freshness of the message, it restores the user's identity information and queries the global Merkle root on the blockchain for verification. After successful verification, key negotiation is conducted with trusted authorities in this domain and trusted authorities in the target domain, and a shared session key is established among end users.

8. The lightweight industrial IoT cross-domain authentication method based on blockchain according to claim 7, characterized in that, The key negotiation uses Chebyshev chaotic mapping to calculate the temporary session key.

9. The lightweight industrial IoT cross-domain authentication method based on blockchain according to claim 1, characterized in that, The global Merkle root is the authentication data stored on the blockchain, and the on-chain storage overhead is constant.

10. A lightweight industrial IoT cross-domain authentication system based on blockchain, applied to the lightweight industrial IoT cross-domain authentication method based on blockchain as described in any one of claims 1-9, characterized in that, include: Initialization module: used to define system parameters through a trusted institution, wherein the system parameters include hash function, symmetric encryption / decryption algorithm, large prime numbers, and parameters for Chebyshev polynomial calculation; Registration module: Used for user registration, edge node registration, and trusted organization registration; Cross-domain authentication module: Used to complete cross-domain identity verification by querying the global Merkel tree root through the blockchain after the user initiates an authentication request and the verification is conducted by a local trusted institution, and the session key is negotiated based on the Chebyshev mapping; The registration module includes: User / Device: Used to initiate authentication requests and perform local verification; Edge server: Used to receive and process sensor data and participate in the authentication process; Trusted Institutions: Responsible for user and device registration, key management, Merkle tree construction, and cross-domain authentication coordination; Blockchain: Used to store the global Merkel tree root and to update and verify the tree root through smart contracts.

Images