Distributed Lightweight Identity Authentication Method Based on Elliptic Curve Cryptography for IIoT

Abstract

This invention designs a distributed lightweight identity authentication method based on elliptic curve cryptography for IIoT, aiming to ensure reliable cross-domain authentication between IIoT devices in different management domains during the IIoT device authentication process. First, it analyzes relevant technologies of IoT and blockchain-integrated authentication mechanisms, theoretically grasping the practical requirements for reliable cross-domain authentication between IIoT devices in different management domains. Second, it analyzes and compares existing IoT and blockchain-integrated authentication mechanisms, proposing a reputation-based lightweight consensus mechanism. Based on this consensus mechanism and considering the characteristics of IIoT devices, it proposes a distributed lightweight identity authentication mechanism based on elliptic curve cryptography to achieve reliable cross-domain authentication between IIoT devices. The design and implementation of a blockchain-based lightweight authentication mechanism for IIoT are completed, effectively ensuring the efficiency and security of authentication between devices, thereby enhancing the reliability of industrial control systems.

Description

Technical Field

[0001] This invention belongs to the field of mutual authentication mechanisms for industrial Internet of Things (IIoT) devices, and particularly relates to a distributed lightweight identity authentication method based on elliptic curve cryptography for IIoT. Background Technology

[0002] As an important subset of the Internet of Things (IoT), the Industrial Internet of Things (IIoT) is being used more and more widely in industrial production. Cross-domain trusted authentication between IIoT devices in different management domains is the key to protecting the security of sensitive data of field devices.

[0003] IoT communication typically requires wireless links to address flexibility and scalability issues. Historically, wireless technologies in industrial applications have largely relied on specialized solutions, such as those developed specifically for connecting mobile or large equipment. In contrast, IIoT devices are characterized by low computing power, relatively low throughput per node, and vulnerability to malicious attacks. Therefore, there is a need to connect a large number of devices to the internet at low cost. Due to limited hardware capabilities and energy resources, latency, energy efficiency, cost, reliability, and security become even more critical characteristics. IIoT technology provides a platform to connect devices to the factory domain, improving productivity and minimizing management costs.

[0004] However, with today's complex manufacturing processes, independently completing the entire product manufacturing process in a single factory is extremely challenging. Therefore, multiple factories completing the entire product manufacturing process is a growing trend. Advances in communication technology have made it easier for devices to connect between factories; however, establishing a lightweight, secure communication mechanism between devices in different management domains is not a simple task due to trust relationships and other unresolved security issues. Typically, different domains do not trust each other because they do not want to disclose their sensitive data to others. However, each domain needs to exchange some sensitive data while simultaneously protecting the security of this data; therefore, it is necessary to propose a secure and efficient cross-domain authentication mechanism. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention provides a distributed, lightweight identity authentication method based on elliptic curve cryptography for IIoT. From the perspective of efficiency and security in IIoT device authentication, it combines blockchain with IIoT to reduce authentication latency and improve device authentication security. Furthermore, it researches and improves the consensus mechanism of blockchain and the elliptic curve cryptography algorithm to enhance authentication efficiency and security between devices, effectively ensuring the success rate of data transmission and thus providing high reliability and security for industrial control systems.

[0006] A distributed, lightweight identity authentication method based on elliptic curve cryptography for IIoT, including the following:

[0007] Step 1: Establish a distributed, lightweight identity authentication mechanism architecture based on elliptic curve cryptography algorithm, and define various entities;

[0008] The identity authentication mechanism architecture consists of entities contained in each factory, namely: multiple IIoT device SNs, a cloud service node CS, and a key generation center RA; multiple domains, namely the cloud server nodes in the factory, together form a blockchain;

[0009] Define E q (a,b) is a non-hypersingly elliptic curve in the form of: y 2 =x 3 +ax+b(mod q); Define G as E q A base point in (a,b) whose order n G The same as q, where q is a prime number greater than 3; define x·G as the dot product of an elliptic curve: x·G = G + G + ... + G(x times); define P + Q as the dot addition of an elliptic curve: P, Q ∈ E q (a,b); Define RTS X Define the timestamp for RA's registration with entity X; define TC. S A temporary credential for the SN; define the ID. X ,TID X RID X Let mk be the real, temporary, and pseudo-identities of entity X; RA Define the master key for RA; define pr X Pub X Let X be the private and public keys of entity X; define s1 and g1 as the random secrets of RA, i.e., random numbers; define r S1 ,r S2 ,p S Let SN be a random secret; define || as the concatenation operation; define TS. X The current timestamp generated for entity X; define * as the finite field Z. q Modular multiplication in the algorithm; define ΔT as the maximum transmission delay associated with the message; define H(.) as the collision-resistant one-way cryptographic hash function;

[0010] Step 2: Identity authentication architecture initialization phase, the key generation center generates the master key and public key;

[0011] The initialization phase includes the following steps: RA selects a non-supersingular elliptic curve E q (a,b): y 2 =x3 The expression +ax+b (mod q) has an "uncertain point (zero)" O on the finite field GF(q), where constants a,b ∈ Z. q ={0,1,2,...,q-1}, thus satisfying 4a 3 +27b 2 ≠0 (mod q); RA selects a base point G∈E q (a,b) has an order n G It is the same size as q, that is, n G ·G=G+G+...+G(n G (times) = O; RA selects a "collision-resistant one-way cryptographic hash function" H(.) and a "reputation-based lightweight consensus mechanism" for the consensus process in the blockchain cloud center; finally, RA in Z q Select your own master key mk RA and the domain parameter {E q (a,b),G,H(·)} is published as a public key;

[0012] Step 3: Establish a lightweight consensus mechanism based on reputation;

[0013] Based on a distributed network model, a lightweight consensus mechanism based on reputation is established. This consensus mechanism consists of two phases: a pre-consensus phase and a consensus phase. These two phases are executed within a limited time period, and the current block is created and published at the end of the limited time.

[0014] Step 3.1: First, in the pre-consensus phase, each validator signs the received transactions and propagates them to four other validators with random IP addresses using the Gossip protocol. Then, these validators merge the received transaction information with transactions received from other validators and send it to four other randomly selected validators. This process continues until a majority of validators reach a consensus on the number and order of transactions. Any transactions sent by industrial IoT devices after the current time period are determined based on the transaction timestamp and will be evaluated by validators in the next time period and placed in the next block. The consensus mechanism uses a balance model to store records, tracking the balance of each account as a global state to ensure that its amount is greater than or equal to its expenditure amount. Therefore, the correctness of transactions is considered from the beginning based on the balance of each account. However, the order of transactions must be considered during the authentication process, so a vector clock is used to sort the transactions.

[0015] Each validator sorts the received transactions, but the order of the transactions is not entirely based on the timestamp t of the transactions created by the industrial IoT devices. c The order, because the timestamp t of the transactions created by the Industrial Internet of Things. cIt may be related to the timestamp t of the transaction received by the validator. r They are the same; therefore, in order to sort transactions, consider the following two conditions, setting the transaction creation timestamp t as the ordering time. c and transaction receive timestamp t r Combined, a custom vector clock can be created;

[0016] Condition 1: If the validator receives two or more transactions with the same creation timestamp (t... c1 =t c2 =...=t cn Then the verifier will determine the transaction based on the transaction reception timestamp (t). r1 <t r2 <... <t rn Sort them;

[0017] Condition 2: If the verifier receives two data points with different creation timestamps (t... c1 <t c2 The transaction is a (t) timestamp, and the receiving timestamp is (t) r1 >t r2 If the transaction creation timestamp is used, then the validator will use the transaction creation timestamp as the primary criterion for ordering transactions.

[0018] Step 3.2: After reaching a pre-consensus, validators enter the consensus phase; in the consensus phase, all validators with equal opportunities announce the transactions they have processed, regardless of the transaction environment, and record the transactions in the current block. Then, the reputation of each validator is calculated.

[0019] Transactions are divided into two categories: valid transactions and invalid transactions; invalid transactions are not evaluated due to initial non-approval, including those that do not conform to the balance model or whose data or structure is invalid; valid transactions are divided into two categories: (1) transactions recorded in block p; (2) transactions not recorded in block p. u ; The validator can record all transactions within the current time period in the current block; if a transaction cannot be recorded in the block due to the validator being closed, hardware problems, power supply, or network issues, it will cause dissatisfaction among the transaction owner (Industrial IoT device); Transaction p recorded in block p r and unrecorded transactions p u It is considered a factor in calculating the reputation of each validator; the reputation of each validator is calculated on two levels;

[0020] Step 3.2.1: Local reputation calculation;

[0021] Local reputation (RL) refers to the reputation of each validator in a block. It is calculated separately for each validator based on the number of valid transactions that the validator can record in the block. Recording transactions of industrial IoT devices is the standard when calculating the local reputation of each validator.

[0022] Therefore, the initial equation for the local reputation of each verifier is defined as:

[0023]

[0024] Where RL represents the local reputation of each validator; p r To record transactions in block p, p u For transactions not recorded in block p, α and β are the weights of valid transactions recorded in the current block and valid transactions not recorded in the current block, respectively, which are 1 and 0. Since the initial validator does not perform transaction evaluation initially, the default reputation value is set to 0.5 in the reputation model. Based on the above, the local reputation calculation formula for each validator is as follows:

[0025]

[0026] Step 3.2.2: Global reputation calculation;

[0027] Global reputation is the sum of a validator's local reputation in each block and the validator's global reputation in the previous block. When calculating a validator's global reputation, it's important to note that validator behavior frequently changes over time; therefore, recent experience is more reliable than historical experience. Thus, based on the influence of time, the formula for calculating global reputation is:

[0028] RG(n)=(α)RL(n)+(1-α)RG(n-1)

[0029] Where RG(n) represents the global reputation value of each validator in the last block (i.e., the current block) within a certain period of time; RG(n-1) represents the global reputation value of the validator before the last block; RL(n) represents the local reputation value of each validator in the last block (i.e., the current block); RG(1) is the initial global reputation value of each validator, set to 0.5; in addition, α is an adjustable parameter, used as a weighting coefficient to determine the impact of time on the calculation of each validator's reputation, set to 0.6;

[0030] The global reputation of each validator is calculated based on their local reputation in the last block (the current block) and their general behavior in previously published blocks. When a validator obtains the highest global reputation value, it must publish a block within time k. However, if a validator does not publish a block within time k, then the validator with the second highest global reputation will be responsible for publishing the block.

[0031] To encourage validators to publish blocks and incentivize other validators, a reward based on global reputation is considered: the Block Creation Reward (CBR). Any validator who achieves the highest global reputation among other validators creates a block, connects it to the blockchain, and publishes and shares the distributed ledger so that all validators hold the same copy of the latest version of the distributed ledger. After block creation and propagation, to encourage validators to improve efficiency and performance, a reward called the Block Creation Reward (CBR) is considered, which directly impacts their global reputation. CBR is a numerical value appended to the block creator's global reputation score.

[0032] Based on the above, the global reputation value, taking into account CBR reputation, is defined as follows:

[0033] RG(n)=δ+(α)RL(n)+(1-α)RG(n-1)

[0034] Where δ is an adjustable weight parameter, which serves as the reward for validators who create blocks;

[0035] Step 3.3: Based on the above steps, establish a lightweight consensus mechanism for reputation;

[0036] Step 3.3.1: Industrial IoT devices send their transactions containing authentication information within a specified time period, assuming the transactions are valid;

[0037] Step 3.3.2: Transactions containing authentication information of industrial IoT devices enter the consensus process; the consensus process itself consists of two parts: pre-consensus and consensus; in addition, validators in the consensus process verify the transactions of industrial IoT devices, put them into blocks, and connect them to cloud servers in the chain, and each cloud server can be a validator;

[0038] Step 3.3.3: In the consensus process, transactions are provided for validators to check their validity and place them in blocks;

[0039] Step 3.3.4: After verifying the transactions, the verifiers reach a pre-consensus on the received transactions, their quantity, and their order;

[0040] Step 3.3.5: After reaching a pre-consensus, the pre-consensus component communicates with the reputation value calculation process at the end of the specified time period; then, each validator announces the transaction and the number of transactions that can be recorded in the current block;

[0041] Step 3.3.6: Calculate the local reputation of each verifier in the local reputation calculation part of the reputation value calculation process, that is, the reputation of each verifier over a period of time;

[0042] Step 3.3.7: After calculating the local reputation, calculate the global reputation of each validator in the global reputation calculation section; the global reputation is the reputation of each validator over all periods.

[0043] Step 3.3.8: After calculating the global reputation of each validator, during the consensus phase, the validators will reach a consensus on the validator with the highest global reputation value to create the current block and put the transactions that it can record into the block;

[0044] Step 3.3.9: The validator with the highest global reputation value publishes the current block;

[0045] Step 4: Registration phase. The industrial IoT device sends a registration request to the key generation center. The cloud server responds to the request from the key generation center and uses a smart contract to call a reputation-based lightweight consensus mechanism to write the public key and credentials of the industrial IoT device as a digital certificate into the blockchain ledger, thus completing the identity registration of the industrial IoT device.

[0046] The registration phase specifically involves: the SN submitting a registration application to the RA, and the RA selecting a real identity ID. S and temporary identity TID S And a random secret. To calculate the pseudo-identity of SN, i.e., RID S =H(ID) S ||s1||mk RA ); RA randomly selects a private key And calculate the corresponding public key Pub S =pr S Temporary credentials for G and SN, i.e., TC S =H(RID) S ||pr S ||mk RA ||RTS S ); where RTS S It is the current registration timestamp of SN; RA uses the credential {(RID)} S ,TID S ,TC S ),H(·),E q (a,b),G,(pr S Pub S Preload SN; in addition, RA will Pub S As the public key of the SN, {(RID) S ,TID S TC S ),H(·),E q (a, b), G, (pr) S Pub S)} as SN's credential C S Send to cloud server CS; CS responds to RA's request and uses a smart contract to invoke a reputation-based lightweight consensus mechanism to transfer SN's public key Pub. S The credentials are written into the blockchain ledger as digital certificates; once the writing is complete, the CS replies to the RA with a message indicating successful writing, and the RA sends the registration result to the SN, thus ending the registration process;

[0047] Step 5: Authentication and Key Protocol Phase. The industrial IoT device sends an authentication request to the cloud server. The cloud server responds to the request and completes identity authentication by calling a reputation-based lightweight consensus mechanism through a smart contract.

[0048] The authentication and key protocol phase specifically involves SN1, as the initiator, first selecting a random secret. and current timestamp TS S1 To calculate r S1 The signature on SN1 sends its authentication request message Send to CS2; CS2 in time Received authentication request message Afterwards, and through Check the validity of the timestamp; if it is valid, verify the signature via the smart contract; if verification is successful, CS2 generates the current timestamp TS. S2 And send the results to SN2;

[0049] SN2 as the responder in time receive and through Check the validity of the timestamp; if it is valid, SN2 will choose a random secret. and current timestamp TS S3 Used for calculation The secret shared with SN1, i.e., the session key, is Session key SK S2S1 The signature is SN2 will send its authentication response message Send to CS1; CS1 at time Received authentication request message Afterwards, and through Check the validity of the timestamp; if it is valid, verify the signature via the smart contract; if verification is successful, CS1 generates the current timestamp TS. S4 And send the result to SN1; if SN1 is in time receive It passes through conditions Verify the timestamp; if it is valid, SN1 calculates the secret (session key) shared with SN2, i.e., SK. S1S2 =x S1 ·Y S2 ;

[0050] Then SN1 creates a new timestamp TS S5 The session key verifier is SKV. S1S2 =H(SK) S1S2 ||TS S5 ), and its verification confirmation message. Send to SN2; if SN2 is in time receive SN2 passed Verify the timestamp; if it is valid, calculate the session key verifier for SKV using SN2. S2S1 =H(SK) S2S1 ||TS S5 ); SN2 inspection of SKV S2S1 Is it related to SKV? S1S2 They are equal; if valid, SN1 and SN2 share the same key SKV in secret communication. S2S1 =SKV S1S2 .

[0051] Beneficial technical effects of the present invention:

[0052] This invention first carefully studied and analyzed relevant documents on authentication mechanisms combining the Internet of Things (IoT) and blockchain, theoretically grasping the practical needs of cross-domain trusted authentication between IIoT devices in different management domains. Second, it analyzed and compared existing technologies related to IoT and blockchain authentication mechanisms, proposing a reputation-based lightweight consensus mechanism. Based on this consensus mechanism and considering the characteristics of IIoT devices, it proposed a distributed lightweight identity authentication mechanism based on elliptic curve cryptography to achieve cross-domain trusted authentication between IIoT devices. The design and implementation of the distributed lightweight identity authentication mechanism based on elliptic curve cryptography were also completed. Attached Figure Description

[0053] Figure 1 A schematic diagram of the lightweight identity authentication mechanism architecture of this invention;

[0054] Figure 2 A schematic diagram of a reputation-based lightweight consensus mechanism framework according to an embodiment of the present invention;

[0055] Figure 3 A schematic diagram of the pre-consensus mechanism based on reputation in an embodiment of the present invention;

[0056] Figure 4Schematic diagrams illustrating different timestamp reception methods in embodiments of the present invention;

[0057] Figure 5 Different schematic diagrams illustrating the creation of timestamps in embodiments of the present invention;

[0058] Figure 6 Schematic diagram of the registration stage in an embodiment of the present invention;

[0059] Figure 7 Schematic diagram of the authentication stage in an embodiment of the present invention;

[0060] Figure 8 Flowchart of the distributed lightweight identity authentication method according to an embodiment of the present invention;

[0061] Figure 9 A schematic diagram illustrating the average latency under different execution counts in an embodiment of the present invention;

[0062] Figure 10 A schematic diagram illustrating throughput under different runtime conditions in an embodiment of the present invention;

[0063] Figure 11 The simulation results of the security of this invention are shown in the figure. Detailed Implementation

[0064] The present invention will be further described below with reference to the accompanying drawings and embodiments;

[0065] A distributed, lightweight authentication method based on elliptic curve cryptography for IIoT is presented in the following flowchart: Figure 8 As shown, it includes the following:

[0066] Step 1: Establish a distributed, lightweight identity authentication mechanism architecture based on elliptic curve cryptography algorithm, and define various entities;

[0067] The identity authentication mechanism architecture consists of entities contained in each factory, namely: multiple IIoT device SNs, a cloud service node CS, and a key generation center RA; multiple domains, i.e., the cloud server nodes in the factories, collectively form a blockchain; such as Figure 1 As shown, Figure 1 A schematic diagram of a lightweight identity authentication mechanism architecture is provided.

[0068] Define E q (a,b) is a non-hypersingly elliptic curve in the form of: y 2 =x 3 +ax+b(mod q); Define G as E q A base point in (a,b) whose order n GThe same as q, where q is a prime number greater than 3; define x·G as the dot product of an elliptic curve: x·G = G + G + ... + G(x times); define P + Q as the dot addition of an elliptic curve: P, Q ∈ E q (a,b); Define RTS X Define the timestamp for RA's registration with entity X; define TC. S A temporary credential for the SN; define the ID. X ,TID X RID X Let mk be the real, temporary, and pseudo-identities of entity X; RA Define the master key for RA; define pr X Pub X Let X be the private and public keys of entity X; define s1 and g1 as the random secrets of RA, i.e., random numbers; define r S1 ,r S2 ,p S Let SN be a random secret; define || as the concatenation operation; define TS. X The current timestamp generated for entity X; define * as the finite field Z. q Modular multiplication in the algorithm; define ΔT as the maximum transmission delay associated with the message; define H(.) as the collision-resistant one-way cryptographic hash function;

[0069] This invention applies the Elliptic Curve Cryptography (ECC) algorithm, a public-key cryptography algorithm based on elliptic curve mathematics. Its security relies on the difficulty of the elliptic curve discrete logarithm problem. Elliptic curve cryptography algorithms have the following two significant advantages:

[0070] (1) Short key length, which means small bandwidth and storage requirements;

[0071] (2) All users can choose different elliptic curves on the same base domain, which allows all users to use the same operations to complete domain operations.

[0072] An elliptic curve can be defined as follows: Let q be a prime number greater than 3. An elliptic curve over a finite field consists of a solution set based on congruences and a specific point called the point at infinity, which are two constants. Let P1 = (x1, y1) and P2 = (x2, y2) be two points on the elliptic curve. The addition and subtraction operations on the elliptic curve are defined as follows:

[0073] (1) -O = O; (2) -P1 = (x1, -y1); (3) O + P1 = P1; (4) If P2 = -P2, then P1 + P2 = O; (5) If P2 ≠ -P1, then P1 + P2 = (x3, y3), where x3 = m2 - x1 - x2, -y3 = m(x3 - x1) + y1.

[0074] According to the addition and subtraction rules defined above, the point obtained by adding two points on an elliptic curve still lies on the original elliptic curve. Therefore, in the equation kP = P + P + ... + P = Q, given k and point P, finding point Q is relatively easy; conversely, given point Q and point P, finding k is quite difficult. This problem is called the discrete logarithm problem of the point group on an elliptic curve. Elliptic curve cryptography is designed using this difficult problem. In practical applications, k is used as the private key, and Q is used as the public key.

[0075] To ensure that the data exchanged between IoT devices originates from a reliable, expected source, random numbers (secrets) generated by each entity in the network and the current timestamp are taken into account. Therefore, it is assumed that the clocks of the various entities (industrial IoT devices) are synchronized, a typical assumption used in authentication and access control protocols in many IoT deployments.

[0076] Step 2: Identity authentication architecture initialization phase, the key generation center generates the master key and public key;

[0077] The initialization phase includes the following steps: RA selects a non-supersingular elliptic curve E q (a,b): y 2 =x 3 The expression +ax+b (mod q) has an "uncertain point (zero)" O in the finite field GF(q), where constants a, b ∈ Z. q ={0, 1, 2, ..., q-1}, thus satisfying 4a 3 +27b 2 ≠0 (mod q); RA selects a base point G∈E q (a,b) has an order n G It is the same size as q, that is, n G ·G=G+G+...+G(n G (times) = O; RA selects a "collision-resistant one-way cryptographic hash function" H(.) (e.g., the SHA-256 hash algorithm can be used) and a "reputation-based lightweight consensus mechanism" for the consensus process in the blockchain cloud center; finally, RA in Z q Select your own master key mk RA and the domain parameter {E q (a,b),G,H(·)} is published as a public key;

[0078] Step 3: Establish a lightweight consensus mechanism based on reputation;

[0079] Based on a distributed network model, a lightweight consensus mechanism based on reputation is established. This consensus mechanism consists of two phases: a pre-consensus phase and a consensus phase. These two phases are executed within a limited time period, and the current block is created and published at the end of the limited time.

[0080] Introducing a reputation mechanism in a distributed network can effectively mitigate the negative impact of non-cooperative nodes. The purpose of the reputation mechanism is to predict the future behavior of nodes to the greatest extent possible by observing the historical behavior characteristics of nodes and adopting reasonable measures, thereby isolating non-cooperative nodes and improving the overall availability and efficiency of the distributed network.

[0081] The credit model is based on the historical interaction records between nodes. By analyzing the correlation between different factors and node behavior, the influencing factors of the composite node reputation value are defined, so that the reputation value can truly reflect the behavioral characteristics of the nodes. Based on the characteristics of distributed networks, the credit model should include the following three requirements: the determinacy of node identity; historical behavior records of nodes under a given identity; and the establishment of corresponding calculation methods to analyze the credibility of nodes with different identities. Based on these requirements, a distributed reputation model is established.

[0082] Considering the computing power, quantity, and security of Industrial Internet of Things (IIoT) devices, a reputation-based lightweight consensus mechanism is proposed. The main idea of ​​this mechanism is based on the concept of transactions between IIoT devices, using a reputation model to determine the target entities for creating and publishing blocks and connecting them to the blockchain. In other words, the most qualified node is designated to create a block, and the node is connected to the blockchain based on its reputation, calculated according to its transaction history, without considering the higher computing power or higher assets used in the PoW and PoS consensus mechanisms of Bitcoin and Ethereum.

[0083] By using the gossip protocol to propagate transactions and information among nodes, each node can send its information to other random nodes. Since nodes synchronize all data (including authentication information and the clock) via a vector clock when receiving transactions from other nodes, duplicate transactions can be detected, and the node will not republish the duplicate transaction. Therefore, network load does not increase significantly, and computational time complexity is relatively low. Figure 2 This demonstrates a lightweight consensus mechanism framework based on reputation.

[0084] Step 3.1: First, in the pre-consensus phase, each validator signs the received transactions and propagates them to four other validators with random IP addresses using the Gossip protocol. Then, these validators merge the received transaction information with transactions received from other validators and send it to four other randomly selected validators. This process continues until a majority of validators (60%) reach a consensus on the number and order of transactions. Any transactions sent by industrial IoT devices after the current time period (determined by the transaction timestamp) will be evaluated by validators in the next time period and placed in the next block. The consensus mechanism uses a balance model to store records, tracking the balance of each account as a global state to ensure that its amount is greater than or equal to its expenditure amount. Therefore, the correctness of transactions is considered from the beginning based on the balance of each account. However, the order of transactions must be considered during the authentication process, so a vector clock is used to sort the transactions. Figure 3 A schematic diagram of the pre-consensus mechanism based on reputation is shown.

[0085] Each validator sorts the received transactions, but the order of the transactions is not entirely based on the timestamp t of the transactions created by the industrial IoT devices. c The order, because the timestamp t of the transactions created by the Industrial Internet of Things. c It may be related to the timestamp t of the transaction received by the validator. r They are the same; therefore, in order to sort transactions, consider the following two conditions, setting the transaction creation timestamp t as the ordering time. c and transaction receive timestamp t r Combined, a custom vector clock can be created;

[0086] Condition 1: If the validator receives two or more transactions with the same creation timestamp (t... c1 =t c2 =...=t cn Then the verifier will determine the transaction based on the transaction reception timestamp (t). r1 <t r2 <... <t rn Sort them; Figure 4 The diagram shows different timestamps received.

[0087] Condition 2: If the verifier receives two data points with different creation timestamps (t... c1 <t c2 The transaction is a (t) timestamp, and the receiving timestamp is (t) r1 >t r2 If the transaction creation timestamp is used, then the validator will use the transaction creation timestamp as the primary criterion for ordering transactions. Figure 5 This shows different diagrams illustrating the creation timestamps;

[0088] Step 3.2: After reaching a pre-consensus, validators enter the consensus phase; in the consensus phase, all validators with equal opportunities announce the transactions they have processed, regardless of the transaction environment, and record the transactions in the current block. Then, the reputation of each validator is calculated.

[0089] Transactions are divided into two categories: valid transactions and invalid transactions; invalid transactions are not evaluated due to initial non-approval, including those that do not conform to the balance model or whose data or structure is invalid; valid transactions are divided into two categories: (1) transactions recorded in block p; (2) transactions not recorded in block p. u ; The validator can record all transactions within the current time period in the current block; if a transaction cannot be recorded in the block due to the validator being closed, hardware problems, power supply, or network issues, it will cause dissatisfaction among the transaction owner (Industrial IoT device); Transaction p recorded in block p r and unrecorded transactions p u It is considered a factor in calculating the reputation of each validator; the reputation of each validator is calculated on two levels;

[0090] Step 3.2.1: Local reputation calculation;

[0091] Local reputation (RL) refers to the reputation of each validator in a block. It is calculated separately for each validator based on the number of valid transactions that the validator can record in the block. Recording transactions of industrial IoT devices is the standard when calculating the local reputation of each validator.

[0092] Therefore, the initial equation for the local reputation of each verifier is defined as:

[0093]

[0094] Where RL represents the local reputation of each validator; p r To record transactions in block p, p u For transactions not recorded in block p, α and β are the weights of valid transactions recorded in the current block and valid transactions not recorded in the current block, respectively, which are 1 and 0. Since the initial validator does not perform transaction evaluation initially, the default reputation value is set to 0.5 in the reputation model. Based on the above, the local reputation calculation formula for each validator is as follows:

[0095]

[0096] Step 3.2.2: Global reputation calculation;

[0097] Global reputation is the sum of a validator's local reputation in each block and the validator's global reputation in the previous block. When calculating a validator's global reputation, it's important to note that validator behavior frequently changes over time; therefore, recent experience is more reliable than historical experience. Thus, based on the influence of time, the formula for calculating global reputation is:

[0098] RG(n)=(α)RL(n)+(1-α)RG(n-1)

[0099] Where RG(n) represents the global reputation value of each validator in the last block (i.e., the current block) within a certain period of time; RG(n-1) represents the global reputation value of the validator before the last block; RL(n) represents the local reputation value of each validator in the last block (i.e., the current block); RG(1) is the initial global reputation value of each validator, set to 0.5; in addition, α is an adjustable parameter, used as a weighting coefficient to determine the impact of time on the calculation of each validator's reputation, set to 0.6;

[0100] The global reputation of each validator is calculated based on their local reputation in the last block (the current block) and their general behavior in previously published blocks. When a validator obtains the highest global reputation value, it must publish a block within time k. However, if a validator does not publish a block within time k, then the validator with the second highest global reputation will be responsible for publishing the block.

[0101] To incentivize validators to publish blocks and to motivate other validators, a global reputation reward is considered: Create Block Rewards (CBR). Any validator who achieves the highest global reputation among other validators creates a block, connects it to the blockchain, and publishes and shares the distributed ledger so that all validators hold the same copy of the latest version of the distributed ledger. After creating and propagating a block, to encourage validators to improve efficiency and performance, a reward called the Block Creation Reward (CBR) is considered, which directly impacts their global reputation. CBR is a numerical value appended to the block creator's global reputation score.

[0102] Based on the above, the global reputation value, taking into account CBR reputation, is defined as follows:

[0103] RG(n)=δ+(α)RL(n)+(1-α)RG(n-1)

[0104] Where δ is an adjustable weight parameter, which serves as the reward for validators who create blocks;

[0105] Step 3.3: Based on the above steps, establish a lightweight consensus mechanism for reputation;

[0106] Step 3.3.1: Industrial IoT devices send their transactions containing authentication information within a specified time period, assuming the transactions are valid;

[0107] Step 3.3.2: Transactions containing authentication information of industrial IoT devices enter the consensus process; the consensus process itself consists of two parts: pre-consensus and consensus; in addition, validators in the consensus process verify the transactions of industrial IoT devices, put them into blocks, and connect them to cloud servers in the chain, and each cloud server can be a validator;

[0108] Step 3.3.3: In the consensus process, transactions are provided for validators to check their validity and place them in blocks;

[0109] Step 3.3.4: After verifying the transactions, the verifiers reach a pre-consensus on the received transactions, their quantity, and their order;

[0110] Step 3.3.5: After reaching a pre-consensus, the pre-consensus component communicates with the reputation value calculation process at the end of the specified time period; then, each validator announces the transaction and the number of transactions that can be recorded in the current block;

[0111] Step 3.3.6: Calculate the local reputation of each verifier in the local reputation calculation part of the reputation value calculation process, that is, the reputation of each verifier over a period of time;

[0112] Step 3.3.7: After calculating the local reputation, calculate the global reputation of each validator in the global reputation calculation section; the global reputation is the reputation of each validator over all periods.

[0113] Step 3.3.8: After calculating the global reputation of each validator, during the consensus phase, the validators will reach a consensus on the validator with the highest global reputation value to create the current block and put the transactions that it can record into the block;

[0114] Step 3.3.9: The validator with the highest global reputation value publishes the current block;

[0115] Step 4: Registration phase. The industrial IoT device sends a registration request to the key generation center. The cloud server responds to the request from the key generation center and uses a smart contract to call a reputation-based lightweight consensus mechanism to write the public key and credentials of the industrial IoT device as a digital certificate into the blockchain ledger, thus completing the identity registration of the industrial IoT device.

[0116] The registration phase specifically involves: the SN submitting a registration application to the RA, and the RA selecting a real identity ID. S and temporary identity TID S And a random secret. To calculate the pseudo-identity of SN, i.e., RID S =H(ID) S ||s1||mk RA ); RA randomly selects a private key And calculate the corresponding public key Pub S =pr S Temporary credentials for G and SN, i.e., TC S =H(RID) S ||pr S ||mk RA ||RTS S ); where RTS S It is the current registration timestamp of SN; RA uses the credential {(RID)} S ,TID S ,TC S ),H(·),E q (a,b),G,(pr S Pub S Preload SN; in addition, RA will Pub S As the public key of the SN, {(RID) S ,TID S ,TC S ),H(·),E q (a,b),G,(pr S Pub S )} as SN's credential C S Send to cloud server CS; CS responds to RA's request and uses a smart contract to invoke a reputation-based lightweight consensus mechanism to transfer SN's public key Pub. S The credentials are written into the blockchain ledger as digital certificates; once the writing is complete, the CS replies to the RA with a message indicating successful writing, and the RA sends the registration result to the SN, thus ending the registration process; Figure 6 A diagram illustrating the registration phase is shown.

[0117] Step 5: Authentication and Key Protocol Phase. The industrial IoT device sends an authentication request to the cloud server. The cloud server responds to the request and completes identity authentication by calling a reputation-based lightweight consensus mechanism through a smart contract.

[0118] The authentication and key protocol phase specifically involves SN1, as the initiator, first selecting a random secret. and current timestamp TS S1 To calculate r S1 The signature on SN1 sends its authentication request message Send to CS2; CS2 in time Received authentication request message Afterwards, and through Check the validity of the timestamp; if it is valid, verify the signature via the smart contract; if verification is successful, CS2 generates the current timestamp TS. S2 And send the results to SN2;

[0119] SN2 as the responder in time receive and through Check the validity of the timestamp; if it is valid, SN2 will choose a random secret. and current timestamp TS S3 Used for calculation The secret shared with SN1, i.e., the session key, is Session key SK S2S1 The signature is SN2 will send its authentication response message Send to CS1; CS1 at time Received authentication request message Afterwards, and through Check the validity of the timestamp; if it is valid, verify the signature via the smart contract; if verification is successful, CS1 generates the current timestamp TS. S4 And send the result to SN1; if SN1 is in time receive It passes through conditions Verify the timestamp; if it is valid, SN1 calculates the secret (session key) shared with SN2, i.e., SK. S1S2 =x S1 ·Y S2 ;

[0120] Then SN1 creates a new timestamp TS S5 The session key verifier is SKV. S1S2 =H(SK) S1S2 ||TS S5 ), and its verification confirmation message. Send to SN2; if SN2 is in time receive SN2 passed Verify the timestamp; if it is valid, calculate the session key verifier for SKV using SN2. S2S1 =H(SK) S2S1 ||TS S5 ); SN2 inspection of SKV S2S1 Is it related to SKV? S1S2 They are equal; if valid, SN1 and SN2 share the same key SKV in secret communication.S2S1 =SKV S1S2 . Figure 7 A diagram illustrating the certification process is shown.

[0121] The average latency of the proposed solution is compared and analyzed with other existing solutions (DLBA-IoT and S-LoRaWAN). Figure 9 As shown, among the three authentication mechanisms, DLBA-IoT has an average latency of approximately 823 milliseconds, which is about 155 milliseconds higher than ELSA. ELAM reduces latency by approximately 7.83% compared to S-LoRaWAN. This is because ELSA uses the discrete logarithm problem on elliptic curves for its theoretical foundation, resulting in low algorithm complexity and faster key generation. Furthermore, ELAM is tailored to the characteristics of industrial IoT networks, setting up numerous operations on distributed nodes with high computing and storage capabilities, distributing low-complexity computations to IoT devices, thus reducing the burden on the devices.

[0122] Throughput is a crucial indicator of the performance of an authentication mechanism; it refers to the number of transactions processed within a given time period, expressed as TPS (transactions per second). Figure 10 As shown, the number of authentication requests processed per second by ELAM increases with runtime and consistently exceeds that of the other two methods. In ELAM, the reliance on elliptic curve cryptography with shorter key lengths improves processing and computation speed, reduces processing latency, and enhances scalability. The use of the Gossip protocol to distribute and propagate transactions between nodes further increases throughput while improving system performance. This represents an approximately 11.35% throughput improvement compared to S-LoRaWAN.

[0123] Formal security verification was performed using the AVISPA tool. Because AVISPA implements the DY threat model, it can detect passive or active replay attacks and man-in-the-middle attacks by adversaries during communication. Simulation results for the security verification of the D2D authentication phase in ELAM are as follows: Figure 11 As shown, ELAM can therefore defend against replay attacks and man-in-the-middle attacks.

Claims

1. A distributed lightweight identity authentication method based on elliptic curve cryptography for IIoT, characterized in that, Includes the following: Step 1: Establish a distributed, lightweight identity authentication mechanism architecture based on elliptic curve cryptography algorithm, and define various entities; Step 2: Identity authentication architecture initialization phase, the key generation center generates the master key and public key; Step 3: Establish a lightweight consensus mechanism based on reputation; Based on a distributed network model, a lightweight consensus mechanism based on reputation is established. This consensus mechanism consists of two phases: a pre-consensus phase and a consensus phase. These two phases are executed within a limited time period, and the current block is created and published at the end of the limited time. Step 3.1: First, in the pre-consensus phase, each validator signs the received transactions and uses the Gossip protocol to propagate them to four other validators with random IP addresses; then, these validators merge the received transaction information with the transactions received from other validators and send it to four other randomly selected validators. This process continues until a majority of validators reach a consensus on the number and order of transactions. Any transactions sent by industrial IoT devices after the current time period are determined based on the transaction timestamp and evaluated by validators in the next time period, then placed in the next block. The consensus mechanism uses a balance model to store records, tracking each account's balance as a global state to ensure that its amount is greater than or equal to its expenditure. Therefore, the correctness of transactions is considered from the outset based on each account's balance. However, the order of transactions must be considered during the authentication process, so a vector clock is used to sort the transactions. Each validator sorts the received transactions, but the order of the transactions is not entirely based on the timestamps of the transactions created by the industrial IoT devices. The order, because of the timestamps of transactions created by the Industrial Internet of Things. Possibly related to the timestamp of the transaction received by the validator. They are the same; therefore, in order to sort transactions, consider the following two conditions regarding the timestamps of transaction creation. and transaction receive timestamp Combined, a custom vector clock can be created; Condition 1: If the validator receives two or more transactions with the same creation timestamp. Then the verifier will determine the transaction reception timestamp. Sort them; Condition 2: If the verifier receives two data points with different creation timestamps The transaction, and the received timestamp is Then the transaction creation timestamp will be used as the primary criterion for validators to sort transactions; Step 3.2: After reaching a pre-consensus, validators enter the consensus phase; in the consensus phase, all validators with equal opportunities announce the transactions they have processed, regardless of the transaction environment, and record the transactions in the current block. Then, the reputation of each validator is calculated. Transactions are divided into two categories: valid transactions and invalid transactions; invalid transactions are not evaluated because they are not initially approved, including those that do not conform to the balance model or whose data or structure is invalid; valid transactions are divided into two categories, namely: (1) those recorded in blocks (2) Transactions not recorded in the block Transactions in ; The validator can record all transactions within the current time period in the current block; If a transaction cannot be recorded in a block due to a validator shutdown, hardware issues, power problems, or network problems, it will lead to dissatisfaction from the transaction owner; block Transactions recorded in and unrecorded transactions It is considered a factor in calculating the reputation of each validator; the reputation of each validator is calculated on two levels; Step 3.3: Based on Steps 3.1 and 3.2 above, establish a lightweight consensus mechanism based on reputation; Step 4: Registration phase. The industrial IoT device sends a registration request to the key generation center. The cloud server responds to the request from the key generation center and uses a smart contract to call a reputation-based lightweight consensus mechanism to write the public key and credentials of the industrial IoT device as a digital certificate into the blockchain ledger, thus completing the identity registration of the industrial IoT device. Step 5: Authentication and Key Protocol Phase. The industrial IoT device sends an authentication request to the cloud server. The cloud server responds to the request and completes identity authentication by calling a reputation-based lightweight consensus mechanism through a smart contract.

2. The distributed lightweight identity authentication method based on elliptic curve cryptography for IIoT as described in claim 1, characterized in that, The identity authentication mechanism architecture described in step 1 consists of entities contained in each factory, and the entities are: multiple IIoT devices. A cloud service node and a key generation center Multiple domains, i.e., cloud server nodes in the factory, together form a blockchain; definition It takes the form of a non-hypersonic elliptic curve: ;definition for A base point, whose order and The same size, among which It is a prime number greater than 3; definition Dot product of an elliptic curve: ;definition Addition of points on an elliptic curve: ;definition for To entity The registration timestamp; definition for Temporary credentials; definition For entities Real, temporary, and pseudo identities; definition for Master key; definition For entities Private and public keys; definition for The random secret is the random number; definition for Random secret; definition For concatenation operation; defined For entities The generated current timestamp; definition For a finite field Modular multiplication in Chinese; definition The maximum transmission delay associated with the message; defined It is a collision-resistant one-way cryptographic hash function.

3. The distributed lightweight identity authentication method based on elliptic curve cryptography for IIoT as described in claim 1, characterized in that, Step 2, the initialization phase, includes the following steps: Choose a non-supersingular elliptic curve : In a finite field There is an "uncertain point, i.e., zero point" above. ,constant Thus satisfying ; Select a base point Its order and The same size, that is ; Choose a "collision-resistant one-way cryptographic hash function". And a "reputation-based lightweight consensus mechanism" for the consensus process in blockchain cloud centers; finally, exist Choose your own master key and the domain parameters Published as a public key.

4. The distributed lightweight identity authentication method based on elliptic curve cryptography for IIoT according to claim 1, characterized in that, Step 3.2 specifically involves: Step 3.2.1: Local reputation calculation; Local credit It refers to the reputation of each validator in the block, which is calculated separately for each validator based on the number of valid transactions that the validator can record in the block; when calculating the local reputation of each validator, recording transactions of industrial IoT devices is the standard. Therefore, the initial equation for the local reputation of each verifier is defined as: ； in This represents the local reputation of each validator; To record in the block The affairs in Not recorded in the block The affairs in , These are the weights of valid transactions recorded in the current block and valid transactions not recorded in the current block, which are 1 and 0 respectively. Since the initial validator does not perform transaction evaluation initially, the default reputation value is set to 0.5 in the reputation model. Based on the above, the local reputation calculation formula for each validator is as follows: ； Step 3.2.2: Global reputation calculation; Global reputation is the sum of a validator's local reputation in each block and the validator's global reputation in the previous block. When calculating a validator's global reputation, it's important to note that validator behavior frequently changes over time; therefore, recent experience is more reliable than historical experience. Thus, based on the influence of time, the formula for calculating global reputation is: ； in This represents the global reputation value of each validator within a certain period of time, specifically in the last block (i.e., the current block). This represents the validator's global reputation value before the last block; This represents the local reputation value of each validator in the last block, i.e., the current block; This is the initial global reputation value for each validator, set to 0.5; in addition, It is an adjustable parameter that acts as a weighting factor to determine the impact of time on the calculation of each validator's reputation. (Setting...) It is 0.6; The global reputation of each validator is calculated based on their local reputation in the last block (the current block) and their general behavior in previously published blocks. When a validator obtains the highest global reputation value, it must publish a block within time k. However, if a validator does not publish a block within time k, then the validator with the second highest global reputation will be responsible for publishing the block. To encourage validators to publish blocks and to incentivize other validators, a global reputation reward is considered: Block Creation Reward (CBR), which is awarded to any validator who can achieve the highest global reputation among other validators to create a block and connect it to the blockchain, as well as to publish and share the distributed ledger so that all validators hold the same copy of the latest version of the distributed ledger. After blocks are created and propagated, to encourage validators to improve efficiency and performance, a reward called Block Creation Reward (CBR) is considered, which has a direct impact on their global reputation. CBR is a value that is attached to the global reputation value of the block creator. Based on the above, the global reputation value, taking into account CBR reputation, is defined as follows: ； in It is an adjustable weight parameter, used as a reward for validators who create blocks.

5. The distributed lightweight identity authentication method based on elliptic curve cryptography for IIoT according to claim 1, characterized in that, Step 3.3 specifically involves: Step 3.3.1: Industrial IoT devices send their transactions containing authentication information within a specified time period, assuming the transactions are valid; Step 3.3.2: Transactions containing authentication information from industrial IoT devices enter the consensus process; The consensus process itself consists of two parts: pre-consensus and consensus; in addition, validators in the consensus process are responsible for verifying transactions of industrial IoT devices, putting them into blocks, and connecting them to cloud servers in the chain, and each cloud server can be a validator. Step 3.3.3: In the consensus process, transactions are used by validators to check their validity and place them in blocks; Step 3.3.4: After verifying the transactions, the verifiers reach a pre-consensus on the received transactions, their quantity, and their order; Step 3.3.5: After reaching a pre-consensus, the pre-consensus component communicates with the reputation value calculation process at the end of the specified time period; then, each validator announces the transaction and the number of transactions that can be recorded in the current block; Step 3.3.6: Calculate the local reputation of each verifier in the local reputation calculation part of the reputation value calculation process, that is, the reputation of each verifier over a period of time; Step 3.3.7: After calculating the local reputation, calculate the global reputation of each validator in the global reputation calculation section; the global reputation is the reputation of each validator over all periods. Step 3.3.8: After calculating the global reputation of each validator, during the consensus phase, the validators will reach a consensus on the validator with the highest global reputation value to create the current block and put the transactions that it can record into the block; Step 3.3.9: The validator with the highest global reputation value publishes the current block.

6. The distributed lightweight identity authentication method based on elliptic curve cryptography for IIoT according to claim 1, characterized in that, Step 4, the registration phase, specifically involves: Towards Submit a registration application. Choose a real identity and temporary identity And a random secret. To calculate The false identity, that is ; Randomly select a private key And calculate the corresponding public key. and Temporary voucher ;in, yes The current registration timestamp; Use vouchers preloading ;also, Will As The public key will As voucher Send to cloud server ; response The request will be processed through a smart contract that invokes a reputation-based lightweight consensus mechanism. public key And the credentials are written into the blockchain ledger as digital certificates; once the writing is complete, Towards Reply with a message indicating successful write. Send the registration results to The registration process is now complete.

7. The distributed lightweight identity authentication method based on elliptic curve cryptography for IIoT according to claim 1, characterized in that, Step 5, the authentication and key protocol phase, specifically includes: As the initiator, first choose a random secret. and current timestamp To calculate , , The signature on ; Its authentication request message Send to In time Received authentication request message Afterwards, and through Check the validity of the timestamp; If it is valid, then verify the signature via the smart contract; if verification is successful... Generate current timestamp Send the results to ; As the respondent in time receive and through Check the validity of the timestamp; If it is valid, A random secret will be chosen. and current timestamp Used for calculation , ,and The shared secret, i.e., the session key, is Session key The signature is ; Its authentication response message Send to ; In time Received authentication request message Afterwards, and through Check the validity of the timestamp; If it is valid, then verify the signature via the smart contract; if verification is successful... Generate current timestamp Send the results to ;if In time receive It is through conditions Verify timestamp; If it is valid, Calculation and The shared secret (session key), i.e. ; Then Create a new timestamp The session key verifier is calculated as follows: and its verification confirmation message Send to ;if In time receive ; pass Verify timestamp; If it is valid, Calculate the session key verifier as ; examine Whether or not Equal; if valid, and Sharing the same key in secret communications .

Images