Internet of Things identity management method and system based on block chain

Abstract

The invention discloses an Internet of Things identity management method and system based on a block chain, and relates to the technical field of fusion block chains, the method comprises identity prefabrication, dynamic authorization, security interaction and identity management and control, and in the identity prefabrication stage, a unique security seed is injected into equipment, a key pair is generated, an identifier is decentralized, and an access credential is decentralized. After verification of a block chain smart contract, writing the data into an alliance chain main chain to complete identity anchoring; dynamically authorizing through an attribute-based access control model, and setting a fine-grained permission boundary according to an access credential; the security interaction adopts a DID bidirectional authentication and batch signature verification technology to process a high-concurrency request, an instruction is verified and executed through a security module after being signed and packaged, and an audit triple is synchronously constructed for storage; and identity management and control triggers key rotation through an intelligent contract rule engine, so that the full-life-cycle safety of the identity is ensured, and the safety risk caused by permission abuse is effectively reduced.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, specifically to a blockchain-based IoT identity management method and system. Background Technology

[0002] With the rapid popularization of IoT technology, the number of devices connected to the network in scenarios such as industrial IoT, smart cities, and smart homes is growing exponentially. Device identity management has become the core cornerstone for ensuring the safe and stable operation of the system. Therefore, a blockchain-based IoT identity management method and system are needed.

[0003] Current mainstream IoT identity management solutions mainly rely on centralized public key infrastructures or third-party certification authorities.

[0004] The existing technology has the following technical problems: 1. The authentication system based on centralized CA will completely paralyze the authentication process of the entire system once the central server is attacked or fails, and the access and interaction of all devices will be suspended, which will bring fatal security risks to the Internet of Things system.

[0005] 2. In traditional solutions, device identities are mostly represented by static certificates, which makes it difficult to support dynamic, fine-grained permission adjustments. In scenarios where devices frequently join or leave the network, or where device roles or usage scenarios change, static identity management cannot adapt quickly, easily leading to permission abuse or business interruption.

[0006] 3. Audit logs in traditional systems are usually stored on a central server and lack an effective anti-tampering mechanism. Whether it is unauthorized operation by internal personnel or malicious tampering by external attackers, the logs may be distorted, which cannot meet the high-reliability traceability requirements in IoT scenarios. Once a security incident occurs, it is difficult to accurately identify the responsible party.

[0007] 4. In the multi-vendor, multi-platform collaborative IoT ecosystem, the identity authentication standards between different systems are not unified, making it difficult to achieve cross-platform mutual recognition of device identities, forming trust silos, which seriously hinders the large-scale deployment and collaborative operation of IoT systems.

[0008] 5. Existing solutions are difficult to adapt to the resource constraints of heterogeneous IoT environments. Among the massive number of IoT devices, there are industrial control devices with strong computing capabilities as well as simple sensors with limited memory and computing power. Traditional identity authentication solutions have high computational overhead and cannot run efficiently on resource-constrained devices. They also cannot meet the real-time processing requirements of high-concurrency instructions in industrial scenarios. Summary of the Invention

[0009] In view of the above-mentioned technical shortcomings, the purpose of this invention is to provide a blockchain-based Internet of Things (IoT) identity management method and system.

[0010] To solve the above technical problems, the present invention adopts the following technical solution: The present invention provides a blockchain-based IoT identity management method, including the following steps: Step 1, identity pre-creation: During the production stage, a unique security seed is injected into the device. After the device is powered on, a key pair is generated based on the unique security seed. The key pair is combined with the set device metadata to generate a decentralized identifier, and then an access credential is generated. After being verified by the blockchain smart contract, it is written into the consortium blockchain main chain to complete the distributed identity anchoring.

[0011] Step 2, Dynamic Authorization: By pre-setting an attribute-based access control model through blockchain smart contracts, permission boundaries are set based on access credentials.

[0012] Step 3, Secure Interaction: First, identity authentication is completed through a decentralized identifier. Then, batch signature verification technology is used to handle high-concurrency requests. After the instruction is signed and encapsulated by the edge gateway, its legitimacy is verified by the built-in security module or an external security module. After successful verification, the instruction is executed. At the same time, an immutable audit triplet is automatically constructed and stored in the cloud.

[0013] Step 4, Identity Control: The blockchain smart contract has a built-in rule engine that monitors device behavior in real time, sets up a key rotation scheme, generates a new key pair on the device, signs the updated transaction with the old private key, and completes the public key hash update after on-chain verification.

[0014] Preferably, the process of completing the distributed identity anchoring is as follows: The device assembles the decentralized identifier DID, public key hash H(pk), complete device metadata Meta, access credential Token, and issuer signature σ_issuer into a registration transaction Tx_reg={DID,H(pk),Meta,Token,σ_issuer}, where σ_issuer is a signature generated by the blockchain authorized account of the device manufacturer or system integrator using the ECDSA algorithm, and the signature object is {DID,H(pk),Meta}, used to confirm the trustworthiness of the source of the registration information.

[0015] After receiving the registration transaction, the smart contract executes multi-layered verification logic: First, it verifies the legality of the issuer's signature σ_issuer by decrypting the signature using the issuer's public key pk_issuer stored on the chain, and compares the decryption result with the SHA-256 hash value of {DID,H(pk),Meta}. Second, it queries the DID registry contract to confirm that the DID has not been registered repeatedly, thus avoiding identity conflicts. Third, it verifies the integrity of the device metadata Meta format, ensuring that the core fields corresponding to the device type, manufacturer name, firmware version, and installation location are not missing and that the format conforms to the preset specifications. Fourth, it verifies the legality of the access credential Token by comparing the Token hash value with the hash record generated by the contract.

[0016] After verification, the registered transaction is broadcast to all trusted nodes of the consortium blockchain. The nodes use a practical Byzantine fault-tolerant consensus algorithm to confirm the transaction. When a preset number of nodes reach a consensus, the consensus is passed, and the transaction is written into a new block of the consortium blockchain main chain to ensure that it cannot be tampered with.

[0017] After the main chain generates a block containing the new device identity, it sends an identity synchronization event to the security agents of all edge security control layers through a publish-subscribe mechanism. After receiving the event, the security agent stores the device DID, H(pk), Meta_summary, access credential Token, and identity status in a local high-performance cache. After synchronization is completed, the device obtains a distributed identity recognized by the entire network, and the distributed identity anchoring is completed.

[0018] Preferably, the setting of permission boundaries is carried out as follows: Based on the attribute-based access control model preset by the blockchain smart contract, three core attribute dimensions are defined, including subject attributes including subject DID, subject security level and subject role type; resource attributes including resource DID, resource type and resource security level; and environmental attributes including access time window, network environment type and device operating status.

[0019] Access control policies are formulated based on the principle of least privilege. The policy is formally defined as: Policy(DID_s, Attr_s, DID_r, Attr_r, Attr_env, Action) → {Allow, Deny}, where DID_s is the request subject DID, Attr_s is the set of subject attributes, DID_r is the target resource DID, Attr_r is the set of resource attributes, Attr_env is the set of environment attributes, and Action is the request operation. The permission boundaries are precisely defined through policy rules.

[0020] Policy rules are deployed to smart contracts through transactions initiated by authorized management nodes in the consortium blockchain. Transactions must be accompanied by digital signatures from at least a preset number of authorized nodes. After deployment, the smart contract writes the policy rules to the main chain and sends policy update events to all edge security agents. After receiving the events, the edge security agents use an incremental update mode to synchronize the policy rules to their local cache, updating only the changed policy entries to reduce the amount of data transmission.

[0021] On the other hand, the present invention provides a blockchain-based IoT identity management system, including the following modules: an identity pre-processing module, used to inject a unique security seed into the device during the production stage; after the device is powered on, a key pair is generated based on the unique security seed; the key pair is combined with the set device metadata to generate a decentralized identifier, thereby generating an access credential; after being verified by a blockchain smart contract, it is written into the consortium blockchain main chain to complete distributed identity anchoring.

[0022] The dynamic authorization module is used to preset an attribute-based access control model through blockchain smart contracts and set permission boundaries based on access credentials.

[0023] The secure interaction module is used to first complete identity authentication through a decentralized identifier, and then use batch signature verification technology to handle high-concurrency requests. After the instruction is signed and encapsulated by the edge gateway, its legitimacy is verified by the built-in security module or an external security module. After the verification is successful, the instruction is executed. At the same time, an immutable audit triplet is automatically constructed and stored in the cloud.

[0024] The identity management module is used by the built-in rule engine of blockchain smart contracts to monitor device behavior in real time, set key rotation schemes, generate new key pairs for devices, sign and update transactions with the old private key, and complete the public key hash update after on-chain verification.

[0025] The beneficial effects of this invention are as follows: 1. This invention first injects a unique security seed into the device, generating a key pair, a decentralized identifier, and access credentials. After verification by a blockchain smart contract, these are written into the consortium blockchain main chain to complete identity anchoring; dynamic authorization uses an attribute-based access control model to set fine-grained permission boundaries based on access credentials; secure interaction uses DID two-way authentication and batch signature verification technology to handle high-concurrency requests. Instructions are signed and encapsulated and then verified and executed by a security module, while simultaneously building an audit triplet storage; identity management triggers key rotation through a smart contract rule engine, ensuring the security of the identity throughout its entire lifecycle and effectively reducing the security risks caused by permission abuse.

[0026] 2. This invention eliminates centralized trust bottlenecks and enhances system robustness: Relying on a consortium blockchain to build a distributed identity anchoring mechanism, core operations such as identity registration, authorization decisions, and log storage are all completed through on-chain node consensus, completely avoiding the single point of failure risk of centralized architectures. Device identity is deeply bound to the blockchain, ensuring that identity information is tamper-proof and traceable, fundamentally improving the security foundation of the IoT system.

[0027] 3. This invention adapts to complex scenario requirements: The ABAC-based access control strategy combined with short-term access credentials (Tokens) supports dynamic adjustment of permission boundaries based on subject attributes, resource attributes, and environment attributes. The authorization process follows the principle of least privilege, precisely limiting the scope of operations and effective duration, adapting to complex scenarios such as third-party maintenance and temporary device access, effectively reducing security risks caused by permission abuse.

[0028] 4. This invention utilizes a request-permission-execution audit triplet and a main-sidechain hierarchical storage architecture. All critical operation log information is stored on-chain and backed up in the cloud. The main chain stores high-value core data to ensure security, while the sidechain stores high-frequency logs to meet real-time requirements. The triplet is associated with business serial numbers to ensure full-chain traceability. In the event of a security incident or production dispute, data integrity can be quickly verified and responsibilities can be accurately determined.

[0029] 5. This invention supports full lifecycle management of identity and enhances long-term security: Through a key rotation mechanism that combines time-triggered and event-triggered mechanisms, the device can automatically update its key, avoiding the risk of leakage caused by using the same key for a long time; the rule engine built into the smart contract can monitor abnormal device behavior in real time, trigger identity freezing or revocation, realize proactive security defense, and ensure the continuous trustworthiness of the device identity throughout its lifecycle. Attached Figure Description

[0030] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0031] Figure 1 This is a schematic diagram of the implementation steps of the method of the present invention.

[0032] Figure 2 This is a schematic diagram of the system structure connection of the present invention. Detailed Implementation

[0033] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0034] according to Figure 1 As shown, the present invention provides a blockchain-based IoT identity management method, including the following steps: Step 1, Identity Pre-creation: During the production stage, a unique security seed is injected into the device. After the device is powered on, a key pair is generated based on the unique security seed. The key pair is combined with the set device metadata to generate a decentralized identifier, which in turn generates an access credential. After verification by the blockchain smart contract, the credential is written into the consortium blockchain main chain to complete the distributed identity anchoring.

[0035] In one specific embodiment, the key pair generation process is as follows: First, a unique security seed is generated based on the differences in wafer manufacturing process and circuit delay characteristics of the device hardware. Preset the pre-encoding corresponding to each wafer manufacturing process and the post-encoding corresponding to each circuit delay duration. Based on the wafer manufacturing process of the device hardware and the circuit delay duration of each circuit, obtain the pre-encoding and each post-encoding of the device hardware, and combine them to generate a unique security seed.

[0036] After the device is powered on, it enters a self-test process. After the self-test passes, the key generation program is started. The local hardware security unit is called to read the unique security seed Seed. At the same time, a 32-byte random number r is generated by the device's built-in hardware random number generator. The entropy value of the random number r is not less than 256 bits. The key generation operation is performed based on the secp256r1 elliptic curve cryptography algorithm. The specific formula is: (sk,pk) ← KeyGen(Seed||r), where || represents the byte string concatenation operation, KeyGen is the standard ECC key generation function, and the output private key sk is a 256-bit binary number. The public key pk is the coordinates (x,y) of a point on the elliptic curve, which is stored in an uncompressed format.

[0037] In one specific embodiment, the generation of the access credential is carried out as follows: The access credential is a short-term, verifiable digital token, whose structured definition is: Token={DID,H(pk),Meta_summary,T_start,T_exp,Action_set,Nonce,σ_contract}, where Token is the access credential, DID is the decentralized identifier generated in step one, H(pk) is the result of SHA-3-256 hashing of the public key pk, Meta_summary is the summary information of the device metadata, T_start is the credential's effective timestamp, T_exp is the credential's expiration timestamp, Action_set is the set of operations allowed for the device to perform, Nonce is a 128-bit random number generated and allocated by the blockchain smart contract to prevent replay attacks, each Nonce corresponds to only one access credential and expires immediately after use, and σ_contract is the digital signature of the blockchain smart contract, which uses the ECDSA algorithm to sign all fields of the Token except the signature based on the contract's private key.

[0038] It should be noted that Meta_summary is a summary of the device's metadata. It extracts three core fields from the metadata: device type, security level, and manufacturer name, and generates the summary after SHA-256 hashing. Action_set is a set of operations that the device is allowed to perform. It adopts a bitmap encoding format, with each bit corresponding to a specific operation. For example, 0x01 represents "data upload", 0x02 represents "parameter query", and 0x04 represents "command execution", ensuring fine-grained control of permissions.

[0039] The process for generating access credentials is as follows: After the device completes the generation of the decentralized identifier, it submits a credential application transaction to the blockchain smart contract. The transaction includes DID, H(pk), Meta_summary and the requested Action_set. After receiving the transaction, the smart contract verifies the device registration signature using the issuer's public key pre-stored on the chain. After confirming that there are no errors, it generates T_start, T_exp and Nonce, assembles the token according to the above structure and completes the signature.

[0040] In one specific embodiment, the distributed identity anchoring is implemented as follows: The device assembles the decentralized identifier DID, public key hash H(pk), complete device metadata Meta, access credential Token, and issuer signature σ_issuer into a registration transaction Tx_reg={DID,H(pk),Meta,Token,σ_issuer}, where σ_issuer is a signature generated by the blockchain authorized account of the device manufacturer or system integrator using the ECDSA algorithm, and the signature object is {DID,H(pk),Meta}, used to confirm the trustworthiness of the source of the registration information.

[0041] After receiving the registration transaction, the smart contract executes multi-layered verification logic: First, it verifies the legality of the issuer's signature σ_issuer by decrypting the signature using the issuer's public key pk_issuer stored on the chain, and compares the decryption result with the SHA-256 hash value of {DID,H(pk),Meta}. Second, it queries the DID registry contract to confirm that the DID has not been registered repeatedly, thus avoiding identity conflicts. Third, it verifies the integrity of the device metadata Meta format, ensuring that the core fields corresponding to the device type, manufacturer name, firmware version, and installation location are not missing and that the format conforms to the preset specifications. Fourth, it verifies the legality of the access credential Token by comparing the Token hash value with the hash record generated by the contract.

[0042] After verification, the registered transaction is broadcast to all trusted nodes of the consortium blockchain. The nodes use a practical Byzantine fault-tolerant consensus algorithm to confirm the transaction. When a preset number of nodes reach a consensus, the consensus is passed, and the transaction is written into a new block of the consortium blockchain main chain to ensure that it cannot be tampered with.

[0043] After the main chain generates a block containing the new device identity, it sends an identity synchronization event to the security agents of all edge security control layers through a publish-subscribe mechanism. After receiving the event, the security agent stores the device DID, H(pk), Meta_summary, access credential Token, and identity status in a local high-performance cache. After synchronization is completed, the device obtains a distributed identity recognized by the entire network, and the distributed identity anchoring is completed.

[0044] Step 2, Dynamic Authorization: By pre-setting an attribute-based access control model through blockchain smart contracts, permission boundaries are set based on access credentials.

[0045] In one specific embodiment, the setting of permission boundaries is specifically configured as follows: Based on the attribute-based access control model preset by the blockchain smart contract, three core attribute dimensions are defined, including subject attributes such as subject DID, subject security level, and subject role type; resource attributes such as resource DID, resource type, and resource security level; and environmental attributes such as access time window, network environment type, and device operating status.

[0046] Access control policies are formulated based on the principle of least privilege. The policy is formally defined as: Policy(DID_s, Attr_s, DID_r, Attr_r, Attr_env, Action) → {Allow, Deny}, where DID_s is the request subject DID, Attr_s is the set of subject attributes, DID_r is the target resource DID, Attr_r is the set of resource attributes, Attr_env is the set of environment attributes, and Action is the request operation. The permission boundaries are precisely defined through policy rules.

[0047] Policy rules are deployed to smart contracts through transactions initiated by authorized management nodes in the consortium blockchain. Transactions must be accompanied by digital signatures from at least a preset number of authorized nodes. After deployment, the smart contract writes the policy rules to the main chain and sends policy update events to all edge security agents. After receiving the events, the edge security agents use an incremental update mode to synchronize the policy rules to their local cache, updating only the changed policy entries to reduce the amount of data transmission.

[0048] Step 3, Secure Interaction: First, identity authentication is completed through a decentralized identifier. Then, batch signature verification technology is used to handle high-concurrency requests. After the instruction is signed and encapsulated by the edge gateway, its legitimacy is verified by the built-in security module or an external security module. After successful verification, the instruction is executed. At the same time, an immutable audit triplet is automatically constructed and stored in the cloud.

[0049] In one specific embodiment, the identity authentication is completed as follows: the edge gateway sends an authentication request message to the target device. The message includes the edge gateway's DID, public key hash H(pk_gw), 32-byte random number R1, and gateway signature σ_gw, where σ_gw is the ECDSA signature performed by the edge gateway on {DID_gw, H(pk_gw), R1} using its own private key.

[0050] After receiving the request message, the target device queries the public key hash corresponding to the edge gateway DID_gw through its local cache to verify the consistency of H(pk_gw) in the request. Then, it verifies the legality of the signature σ_gw through the public key pk_gw to confirm the trustworthiness of the edge gateway. After successful verification, the device generates a 32-byte random number R2 and performs ECDSA signature on {R1, DID_gw, DID_device, R2} using its own private key to obtain σ_device. The device DID(DID_device), public key hash H(pk_device), R2, and σ_device are assembled into a response message and returned to the edge gateway.

[0051] After receiving the response message, the edge gateway queries the public key hash corresponding to the device DID_device through the local cache, verifies the consistency of H(pk_device), verifies the legality of the signature σ_device through the device public key pk_device, and compares the decryption result with the hash value of {R1,DID_gw,DID_device,R2} to confirm the trustworthiness of the device identity.

[0052] After identity verification is successful, both parties negotiate the session key based on the Elliptic Curve Key Exchange protocol: the edge gateway generates a temporary key pair (sk_temp_gw, pk_temp_gw) and sends pk_temp_gw to the device; the device generates a temporary key pair (sk_temp_device, pk_temp_device) and sends pk_temp_device to the gateway; the edge gateway calculates the shared secret SS_gw=kdf(sk_temp_gw*pk_temp_device) using sk_temp_gw and pk_temp_device; the device calculates the shared secret SS_device=kdf(sk_temp_device*pk_temp_gw) using sk_temp_device and pk_temp_gw, where kdf is an HKDF-SHA256 key derivation function, which takes the shared secret and the hash value of both parties' DIDs as input and outputs a 256-bit session key SK.

[0053] After the device and the edge gateway calculate the session key, the edge gateway sends an acknowledgment message containing the session key hash H(SK) to the device. After the device verifies that H(SK) is consistent with the locally calculated session key hash, it returns an acknowledgment response, and the authentication is completed. If any step in the authentication process fails, an early warning will be issued.

[0054] In one specific embodiment, the batch signature verification technology for handling high-concurrency requests is implemented as follows: The edge gateway sets up a request buffer queue to collect concurrent requests from multiple devices received within a unit time interval. Each request includes the device's instruction content m_i, device signature σ_i, device public key pk_i, and device DID, where i is the device's number and is a positive integer. The edge gateway uses a cryptographically secure random number generator to generate a 16-bit non-zero random number as combination coefficients a_1, a_2 for each valid request. ..., a_n, the random number range is [1, 2^16-1], ensuring that each coefficient is unique and non-zero. Based on elliptic curve point addition, all device signatures are linearly combined to obtain the aggregate signature σ_agg=a_1σ_1+a_2σ_2+...+a_nσ_n. At the same time, all device public keys are linearly combined to obtain the aggregate public key pk_agg=a_1pk_1+a_2pk_2+...+a_npk_n. The aggregation process adopts pre-computation optimization and caches the intermediate results of elliptic curve point addition.

[0055] Perform a SHA-256 hash operation on the instruction content m_i of each request to obtain H(m_i); multiply each H(m_i) with the corresponding combination coefficient a_i to obtain a_iH(m_i); using a parallel computing method, concatenate all a_iH(m_i) in the order of requests, and perform a SHA-256 hash operation on the concatenation result to obtain the aggregate message hash H_agg; use the elliptic curve bilinear pairing function e to verify whether the equation e(σ_agg,G)=e(pk_agg,H_agg) holds, where G is the generator of the elliptic curve.

[0056] If the equation is true, all request signatures are considered valid, and subsequent instructions can be processed. If the equation is false, an invalid signature exists. The scope is narrowed down step by step using a binary search method to locate the request corresponding to the invalid signature, reject the request, and record the exception log.

[0057] In one specific embodiment, the automatic construction of the immutable audit triplet is carried out as follows: the audit triplet includes request information, permission information, and execution information.

[0058] It should be noted that the fields of the request information include: subject DID, target resource DID, instruction content m, instruction sequence number SN, request timestamp T_req, requester signature σ_req, and access credential Token hash value; all fields are hashed using SHA-256 to generate the hash value H(R) of R, ensuring the integrity of R.

[0059] The permission information P includes fields such as: ABAC policy matching result, access credential token verification result, edge gateway authorization signature σ_auth, and edge gateway DID. Similarly, all fields of P are hashed using SHA-256 to generate H(P).

[0060] The ABAC policy matching result includes the matched policy ID and rule content. The access credential verification result includes: valid, invalid, or expired. The execution information E includes the following fields: target device DID, instruction execution result, device status data hash H(State) after execution, execution timestamp T_exec, and device execution signature σ_exec. Perform a SHA-256 hash operation on all fields of E to generate H(E).

[0061] The instruction execution result includes a success or failure code and description. The operating parameters and sensor data of the device after executing the instruction are hashed using SHA-256 to obtain H (State).

[0062] After receiving a request, the edge gateway automatically records the relevant data. After completing the permission verification, the edge gateway constructs the permission information. After the target device executes the instruction, it sends the execution result back to the edge gateway, which then constructs the execution information based on the feedback information.

[0063] The edge gateway calculates the overall hash value of the audit triple and writes it to the consortium blockchain main chain. At the same time, it writes the complete triple data to the consortium blockchain side chain. The side chain uses the ProofofAuthority (PoA) consensus algorithm to store the query index of the triple and a copy of the original data in the cloud.

[0064] In the event of a safety incident or production dispute, the entire chain can be traced by linking the triplet data of the main chain, side chain, and cloud through the business serial number.

[0065] Step 4, Identity Control: The blockchain smart contract has a built-in rule engine that monitors device behavior in real time, sets up a key rotation scheme, generates a new key pair on the device, signs the updated transaction with the old private key, and completes the public key hash update after on-chain verification.

[0066] In one specific embodiment, the key rotation scheme is set as follows: a differentiated rotation period is set according to the device's security level. The device has a built-in high-precision clock module that periodically verifies the timestamps on the chain. When the rotation period is reached, time rotation is automatically triggered. When the device detects a trigger event, event rotation is performed. When time rotation or event rotation is triggered, the local security module is called to generate a new key pair (sk_new, pk_new) based on a new 32-byte random number r_new and a unique security seed Seed, using the secp256r1 elliptic curve ECC algorithm.

[0067] The device signs the key update information using the old private key sk_old, constructing a key update transaction Tx_rotate={DID,H(pk_new),H(pk_old),T_rotate,Revoke_old,σ_old}, where H(pk_new) is the hash of the new public key, H(pk_old) is the hash of the old public key, T_rotate is the rotation timestamp, Revoke_old is the old key revocation identifier, and σ_old is the ECDSA signature of the transaction content by the device using sk_old; the device sends Tx_rotate to the blockchain network.

[0068] After receiving Tx_rotate, the blockchain smart contract verifies the validity of the signature σ_old by using the public key pk_old corresponding to the old public key hash H(pk_old) stored on the chain. It also verifies whether H(pk_old) is consistent with the device public key hash currently stored on the chain. If the verification is successful, the smart contract updates the public key hash corresponding to the DID to H(pk_new), records the key rotation history, and generates a key rotation event.

[0069] It should be noted that triggering events include, but are not limited to, firmware upgrade completion, device security level change, blockchain smart contract detecting abnormal key usage, device identity temporary freezing followed by unfreezing, or administrator manually initiating a rotation command through the blockchain management platform.

[0070] according to Figure 2 As shown, the present invention provides a blockchain-based Internet of Things (IoT) identity management system, which includes the following modules: an identity pre-configuration module, a dynamic authorization module, a secure interaction module, and an identity control module.

[0071] The dynamic authorization module is connected to the identity pre-configuration module and the security interaction module, respectively, and the identity control module is connected to the security interaction module.

[0072] The identity pre-construction module is used to inject a unique security seed into the device during the production stage. After the device is powered on, a key pair is generated based on the unique security seed. The key pair is combined with the set device metadata to generate a decentralized identifier, which in turn generates an access credential. After being verified by the blockchain smart contract, it is written into the consortium blockchain main chain to complete the distributed identity anchoring.

[0073] The dynamic authorization module is used to preset an attribute-based access control model through blockchain smart contracts and set permission boundaries based on access credentials.

[0074] The secure interaction module is used to first complete identity authentication through a decentralized identifier, and then use batch signature verification technology to handle high-concurrency requests. After the instruction is signed and encapsulated by the edge gateway, its legitimacy is verified by the built-in security module or an external security module. After the verification is successful, the instruction is executed. At the same time, an immutable audit triplet is automatically constructed and stored in the cloud.

[0075] The identity management module is used by the built-in rule engine of blockchain smart contracts to monitor device behavior in real time, set key rotation schemes, generate new key pairs for devices, sign and update transactions with the old private key, and complete the public key hash update after on-chain verification.

[0076] The examples described in this invention are not limited to the specific embodiments listed above. The examples are merely illustrative to facilitate understanding of the invention and do not constitute a limitation on the scope of protection of this invention. Any modifications, equivalent substitutions, etc., made within the spirit and principles of this invention should be included within the scope of protection.

[0077] The above description is merely an example and illustration of the concept of the present invention. Those skilled in the art can make various modifications or additions to the specific embodiments described or use similar methods to replace them, as long as they do not deviate from the concept of the invention or exceed the scope defined in this specification, they should all fall within the protection scope of the present invention.

Claims

1. A blockchain-based IoT identity management method, characterized in that, Includes the following steps: Step 1, Identity Pre-creation: During the production phase, a unique security seed is injected into the device. After the device is powered on, a key pair is generated based on the unique security seed. The key pair is combined with the set device metadata to generate a decentralized identifier, which in turn generates an access credential. After being verified by a blockchain smart contract, the credential is written into the consortium blockchain main chain to complete the distributed identity anchoring. Step 2, Dynamic Authorization: By pre-setting an attribute-based access control model through blockchain smart contracts, permission boundaries are set based on access credentials; Step 3, Secure Interaction: First, identity authentication is completed through decentralized identifiers. Then, batch signature verification technology is used to handle high-concurrency requests. After the instruction is signed and encapsulated by the edge gateway, its legality is verified by the built-in security module or external security module. After verification, the instruction is executed. At the same time, an immutable audit triplet is automatically constructed and stored in the cloud. Step 4, Identity Control: The blockchain smart contract has a built-in rule engine that monitors device behavior in real time, sets up a key rotation scheme, generates a new key pair on the device, signs the updated transaction with the old private key, and completes the public key hash update after on-chain verification.

2. The blockchain-based IoT identity management method according to claim 1, characterized in that, The specific process for generating the key pair is as follows: First, a unique security seed is generated based on the differences in wafer manufacturing process and circuit delay characteristics of the device hardware. Pre-encodes corresponding to each wafer manufacturing process and post-encodes corresponding to each circuit delay duration are preset. Based on the wafer manufacturing process and circuit delay duration of the device hardware, the pre-encodes and post-encodes of the device hardware are obtained and combined to generate a unique security seed. After the device is powered on, it enters a self-test process. After the self-test passes, the key generation program is started. The local hardware security unit is called to read the unique security seed Seed. At the same time, a 32-byte random number r is generated by the device's built-in hardware random number generator. The entropy value of the random number r is not less than 256 bits. The key generation operation is performed based on the secp256r1 elliptic curve cryptography algorithm. The specific formula is: (sk,pk) ← KeyGen(Seed||r), where || represents the byte string concatenation operation, KeyGen is the standard ECC key generation function, and the output private key sk is a 256-bit binary number. The public key pk is the coordinates (x,y) of a point on the elliptic curve, which is stored in an uncompressed format.

3. The blockchain-based IoT identity management method according to claim 2, characterized in that, The specific process for generating access credentials is as follows: The access credential is a short-term, verifiable digital token, with a structured definition of: Token={DID,H(pk),Meta_summary,T_start,T_exp,Action_set,Nonce,σ_contract}, where Token is the access credential, DID is the decentralized identifier generated in step one, H(pk) is the result of a SHA-3-256 hash operation on the public key pk, Meta_summary is the summary information of the device's metadata, T_start is the credential's effective timestamp, T_exp is the credential's expiration timestamp, Action_set is the set of operations allowed for the device to perform, Nonce is a 128-bit random number generated and allocated by the blockchain smart contract to prevent replay attacks, each Nonce corresponds to only one access credential and expires immediately after use, and σ_contract is the digital signature of the blockchain smart contract, which uses the ECDSA algorithm to sign all fields of the Token except the signature based on the contract's private key; The process for generating access credentials is as follows: After the device completes the generation of the decentralized identifier, it submits a credential application transaction to the blockchain smart contract. The transaction includes DID, H(pk), Meta_summary and the requested Action_set. After receiving the transaction, the smart contract verifies the device registration signature using the issuer's public key pre-stored on the chain. After confirming that there are no errors, it generates T_start, T_exp and Nonce, assembles the token according to the above structure and completes the signature.

4. The blockchain-based IoT identity management method according to claim 3, characterized in that, The specific implementation process for completing distributed identity anchoring is as follows: The device assembles the decentralized identifier DID, public key hash H(pk), complete device metadata Meta, access credential Token, and issuer signature σ_issuer into a registration transaction Tx_reg={DID,H(pk),Meta,Token,σ_issuer}, where σ_issuer is a signature generated by the blockchain authorized account of the device manufacturer or system integrator using the ECDSA algorithm, and the signature object is {DID,H(pk),Meta}, used to confirm the trustworthiness of the source of the registration information; After receiving the registration transaction, the smart contract executes multi-layered verification logic: First, it verifies the legality of the issuer's signature σ_issuer by decrypting the signature using the issuer's public key pk_issuer stored on the chain, and compares the decryption result with the SHA-256 hash value of {DID,H(pk),Meta}. Second, it queries the DID registry contract to confirm that the DID has not been registered repeatedly, thus avoiding identity conflicts. Third, verify the integrity of the device metadata (Meta) format, ensuring that the core fields corresponding to device type, manufacturer name, firmware version, and installation location are not missing and that the format conforms to the preset specifications. Fourth, verify the legality of the access credential (Token) by comparing the Token hash value with the hash record generated by the contract. After verification, the registered transaction is broadcast to all trusted nodes of the consortium blockchain. The nodes use a practical Byzantine fault-tolerant consensus algorithm to confirm the transaction. When a preset number of nodes reach a consensus, the consensus is passed, and the transaction is written into a new block of the consortium blockchain main chain to ensure that it cannot be tampered with. After the main chain generates a block containing the new device identity, it sends an identity synchronization event to the security agents of all edge security control layers through a publish-subscribe mechanism. After receiving the event, the security agent stores the device DID, H(pk), Meta_summary, access credential Token, and identity status in a local high-performance cache. After synchronization is completed, the device obtains a distributed identity recognized by the entire network, and the distributed identity anchoring is completed.

5. The blockchain-based IoT identity management method according to claim 1, characterized in that, The specific process for setting permission boundaries is as follows: Based on the attribute-based access control model pre-set by blockchain smart contracts, three core attribute dimensions are defined: subject attributes include subject DID, subject security level, and subject role type; resource attributes include resource DID, resource type, and resource security level; and environmental attributes include access time window, network environment type, and device operating status. Access control policies are formulated based on the principle of least privilege. The policy is formally defined as: Policy(DID_s, Attr_s, DID_r, Attr_r, Attr_env, Action) → {Allow, Deny}, where DID_s is the request subject DID, Attr_s is the set of subject attributes, DID_r is the target resource DID, Attr_r is the set of resource attributes, Attr_env is the set of environment attributes, and Action is the request operation. The permission boundaries are precisely defined by policy rules. Policy rules are deployed to smart contracts through transactions initiated by authorized management nodes in the consortium blockchain. Transactions must be accompanied by digital signatures from at least a preset number of authorized nodes. After deployment, the smart contract writes the policy rules to the main chain and sends policy update events to all edge security agents. After receiving the events, the edge security agents use an incremental update mode to synchronize the policy rules to their local cache, updating only the changed policy entries to reduce the amount of data transmission.

6. The blockchain-based IoT identity management method according to claim 5, characterized in that, The identity authentication process is as follows: The edge gateway sends an authentication request message to the target device. The message contains the edge gateway's DID, public key hash H(pk_gw), 32-byte random number R1, and gateway signature σ_gw, where σ_gw is the ECDSA signature performed by the edge gateway on {DID_gw, H(pk_gw), R1} using its own private key. After receiving the request message, the target device queries the public key hash corresponding to the edge gateway DID_gw through its local cache to verify the consistency of H(pk_gw) in the request. Then, it verifies the legality of the signature σ_gw through the public key pk_gw to confirm the trustworthiness of the edge gateway. After successful verification, the device generates a 32-byte random number R2, performs ECDSA signature on {R1, DID_gw, DID_device, R2} using its own private key to obtain σ_device, and assembles the device DID(DID_device), public key hash H(pk_device), R2, and σ_device into a response message and returns it to the edge gateway. After receiving the response message, the edge gateway queries the public key hash corresponding to the device DID_device through the local cache, verifies the consistency of H(pk_device), verifies the legality of the signature σ_device through the device public key pk_device, and compares the decryption result with the hash value of {R1,DID_gw,DID_device,R2} to confirm the trustworthiness of the device identity. After identity verification is successful, both parties negotiate the session key based on the Elliptic Curve Key Exchange protocol: the edge gateway generates a temporary key pair (sk_temp_gw, pk_temp_gw) and sends pk_temp_gw to the device; the device generates a temporary key pair (sk_temp_device, pk_temp_device) and sends pk_temp_device to the gateway; the edge gateway calculates the shared secret SS_gw=kdf(sk_temp_gw*pk_temp_device) using sk_temp_gw and pk_temp_device; the device calculates the shared secret SS_device=kdf(sk_temp_device*pk_temp_gw) using sk_temp_device and pk_temp_gw, where kdf is an HKDF-SHA256 key derivation function, which takes the hash value of the shared secret and the DIDs of both parties as input and outputs a 256-bit session key SK. After the device and the edge gateway calculate the session key, the edge gateway sends an acknowledgment message containing the session key hash H(SK) to the device. After the device verifies that H(SK) is consistent with the locally calculated session key hash, it returns an acknowledgment response, and the authentication is completed. If any step in the authentication process fails, an early warning will be issued.

7. The blockchain-based IoT identity management method according to claim 1, characterized in that, The batch signature verification technology is used to handle high-concurrency requests. The specific processing procedure is as follows: The edge gateway sets up a request buffer queue to collect concurrent requests from multiple devices received within a unit time interval. Each request includes the device's instruction content m_i, device signature σ_i, device public key pk_i, and device DID, where i is the device number and a positive integer. The edge gateway uses a cryptographically secure random number generator to generate a 16-bit non-zero random number as combination coefficients a_1, a_2, ..., a_n for each valid request. The random number range is [1, 2^16-1], ensuring that each coefficient is unique and non-zero. Based on elliptic curve point addition, all device signatures are linearly combined to obtain the aggregate signature σ_agg=a_1σ_1+a_2σ_2+...+a_nσ_n. At the same time, all device public keys are linearly combined to obtain the aggregate public key pk_agg=a_1pk_1+a_2pk_2+...+a_npk_n. The aggregation process is pre-computed and optimized, caching intermediate results of elliptic curve point addition. Perform a SHA-256 hash operation on the instruction content m_i of each request to obtain H(m_i); multiply each H(m_i) with the corresponding combination coefficient a_i to obtain a_iH(m_i); using a parallel computing method, concatenate all a_iH(m_i) in the order of requests, and perform a SHA-256 hash operation on the concatenation result to obtain the aggregate message hash H_agg; use the elliptic curve bilinear pairing function e to verify whether the equation e(σ_agg,G)=e(pk_agg,H_agg) holds true, where G is the generator of the elliptic curve. If the equation is true, all request signatures are considered valid, and subsequent instructions can be processed. If the equation is false, an invalid signature exists. The scope is narrowed down step by step using a binary search method to locate the request corresponding to the invalid signature, reject the request, and record the exception log.

8. The blockchain-based IoT identity management method according to claim 1, characterized in that, The automatic construction process for the immutable audit triplet is as follows: The audit triplet includes request information, permission information, and execution information; After receiving a request, the edge gateway automatically records the relevant data. After completing the permission verification, the edge gateway constructs the permission information. After the target device executes the instruction, it sends the execution result back to the edge gateway, which then constructs the execution information based on the feedback information. The edge gateway calculates the overall hash value of the audit triple and writes it into the consortium blockchain main chain. At the same time, it writes the complete triple data into the consortium blockchain side chain. The side chain uses the ProofofAuthority (PoA) consensus algorithm and stores the query index and original data copy of the triple in the cloud. In the event of a safety incident or production dispute, the entire chain can be traced by linking the triplet data of the main chain, side chain, and cloud through the business serial number.

9. The blockchain-based IoT identity management method according to claim 1, characterized in that, The specific setup process for the key rotation scheme is as follows: Differentiated rotation cycles are set according to the device's security level. The device has a built-in high-precision clock module that periodically verifies the timestamps on the chain. When the rotation cycle is reached, time rotation is automatically triggered. When the device detects a trigger event, event rotation is performed. When time rotation or event rotation is triggered, the local security module is called to generate a new key pair (sk_new, pk_new) based on a new 32-byte random number r_new and a unique security seed Seed, using the secp256r1 elliptic curve ECC algorithm. The device signs the key update information using the old private key sk_old, constructing a key update transaction Tx_rotate={DID,H(pk_new),H(pk_old),T_rotate,Revoke_old,σ_old}, where H(pk_new) is the hash of the new public key, H(pk_old) is the hash of the old public key, T_rotate is the rotation timestamp, Revoke_old is the old key revocation identifier, and σ_old is the ECDSA signature of the transaction content by the device using sk_old; the device sends Tx_rotate to the blockchain network; After receiving Tx_rotate, the blockchain smart contract verifies the validity of the signature σ_old by using the public key pk_old corresponding to the old public key hash H(pk_old) stored on the chain. It also verifies whether H(pk_old) is consistent with the device public key hash currently stored on the chain. If the verification is successful, the smart contract updates the public key hash corresponding to the DID to H(pk_new), records the key rotation history, and generates a key rotation event.

10. An IoT identity management system utilizing the blockchain-based IoT identity management method according to any one of claims 1-9, characterized in that, Includes the following modules: The identity pre-construction module is used to inject a unique security seed into the equipment during the production stage. After the equipment is powered on, a key pair is generated based on the unique security seed. The key pair is combined with the set equipment metadata to generate a decentralized identifier, which in turn generates an access credential. After being verified by the blockchain smart contract, it is written into the consortium blockchain main chain to complete the distributed identity anchoring. The dynamic authorization module is used to preset an attribute-based access control model through blockchain smart contracts and set permission boundaries based on access credentials. The secure interaction module is used to first complete identity authentication through a decentralized identifier, and then use batch signature verification technology to handle high-concurrency requests. After the instruction is signed and encapsulated by the edge gateway, its legality is verified by the built-in security module or an external security module. After the verification is successful, the instruction is executed. At the same time, an immutable audit triplet is automatically constructed and stored in the cloud. The identity management module is used by the built-in rule engine of blockchain smart contracts to monitor device behavior in real time, set key rotation schemes, generate new key pairs for devices, sign and update transactions with the old private key, and complete the public key hash update after on-chain verification.

Images