Method and system for realizing security authentication of Internet of Things equipment based on block chain technology

Abstract

The invention relates to the technical field of Internet of Things, in particular to a method and system for realizing security authentication of Internet of Things equipment based on a block chain technology, and the method comprises the following steps: S1, equipment registration: generating a unique identifier for each piece of Internet of Things equipment on a block chain, and storing the basic information and authentication information of each piece of Internet of Things equipment into the block chain; s2, identity verification: verifying the authenticity of the identity of the equipment through a block chain when the equipment is accessed to the Internet of Things; s3, block chain storage: safely storing identity authentication information of the equipment by using a distributed account book technology of the block chain to ensure that the information cannot be tampered; and S4, smart contract: the smart contract is responsible for an automatic equipment identity verification process to ensure transparency and high efficiency of an authentication process.

Description

Technical Field

[0001] The present invention relates to the technical field of Internet of Things, and in particular to a method and system for implementing security authentication of Internet of Things devices based on blockchain technology. Background Art

[0002] With the rapid development of the Internet of Things, hundreds of millions of devices have been connected to the Internet, forming a huge IoT ecosystem. However, this widespread device interconnection also brings serious security risks. The current IoT device authentication method mainly relies on centralized authentication servers, which has the following major problems:

[0003] 1. Centralization risk: The centralized authentication server becomes the main target of attack. Once it is breached, the security of the entire IoT network will be seriously threatened. In addition, the failure of the server may also cause the authentication of the entire system to fail.

[0004] 2. Tampering and forgery of authentication information: In traditional authentication methods, the authentication information of a device can be easily tampered with or forged, resulting in the inability to accurately verify the identity of the device, which may lead to access by illegal devices and data leakage.

[0005] 3. Lack of trust mechanism: The trust relationship between devices usually relies on a third-party certification agency, but this mechanism cannot completely eliminate the dependence on third parties and adds additional operating costs.

[0006] Therefore, there is an urgent need for a decentralized authentication mechanism with high reliability and transparency to improve the security of IoT devices. Summary of the invention

[0007] The purpose of the present invention is to provide a method and system for realizing security authentication of Internet of Things devices based on blockchain technology, so as to solve the technical problems existing in the prior art.

[0008] In order to achieve the above object, the present invention adopts the following technical solutions:

[0009] In a first aspect, the present invention provides a method for implementing security authentication of an IoT device based on blockchain technology, which comprises the following steps:

[0010] S1. Device registration: Generate a unique identifier for each IoT device on the blockchain and store its basic information and authentication information in the blockchain;

[0011] S2. Authentication: When a device is connected to the IoT network, the authenticity of the device identity is verified through the blockchain;

[0012] S3, blockchain storage: Use blockchain's distributed ledger technology to securely store device identity authentication information to ensure that the information cannot be tampered with;

[0013] S4, Smart Contract: Responsible for automating the device identity authentication process to ensure the transparency and efficiency of the authentication process.

[0014] Preferably, in step S1 device registration, it includes the following steps:

[0015] S11. Generate a device identifier; S12. Generate a key pair; S13. Prepare registration information; S14. Register through a smart contract.

[0016] Preferably, in step S2 identity verification, it includes the following steps:

[0017] S21. Verification request initiated; S22. Query blockchain authentication information; S23. Authentication information comparison; S24. Grant network access permission.

[0018] Preferably, in step S3 blockchain storage, it includes the following steps:

[0019] S31. Hybrid chain architecture; S32. Data access control; S33. Device authentication information is stored in the private chain.

[0020] Preferably, in step S33, the device authentication information is stored in the private chain, which includes the following steps:

[0021] S331, device authentication information encryption; wherein, collect and mark information: collect authentication information of the device, including unique identifier, public key and authentication status; wherein, use symmetric encryption: use AES-256 encryption algorithm to encrypt authentication information, the encryption process uses the security key generated by the device management node to ensure that the key is only shared between authorized nodes, and the encrypted data becomes ciphertext to prevent unauthorized access; S332, generate timestamp and transaction ID; wherein, generate timestamp: obtain the current UTC time of the system, generate a timestamp in a standard format, which is used to mark the creation time of the data; record the current timestamp to ensure the time consistency of the data record; wherein, generate transaction ID: use SHA-256 hash algorithm to generate transaction ID, combine timestamp, device ID and random number to ensure the uniqueness of ID, and provide a unique identifier for each transaction to support traceability;

[0022] S333, data packaging and formatting;

[0023] Among them, data formatting: organize the encrypted data, timestamp and transaction ID into a data packet that complies with the private chain protocol; use JSON format to encapsulate the data to facilitate processing and transmission; the data packet structure includes encrypted data, metadata, timestamp and transaction ID;

[0024] S334. Data on-chain and storage, including: transaction generation and signature, consensus mechanism confirmation, and data storage.

[0025] Preferably, in step S334, the consensus mechanism confirms the selection of a consensus algorithm PBF suitable for the private chain, including:

[0026] (1) Request phase: The client sends a request: The client initiates a transaction request and sends the request to the leader node; The client sends the transaction content: The request includes the transaction data;

[0027] (2) Pre-preparation phase: The leader node receives the request and generates a pre-preparation message after receiving the client request. The leader node broadcasts the pre-preparation message to all replica nodes. The pre-preparation message content includes the requested sequence number, transaction content and the leader node signature.

[0028] (3) Preparation phase: Replica node verification: Each replica node verifies the legitimacy of the pre-prepare message, including the signature and sequence number of the transaction; Prepare message: If the verification passes, the replica node generates a prepare message and broadcasts it to all other nodes; Confirm preparation: After receiving at least 2f+12f+1 prepare messages, the node enters the next phase;

[0029] (4) Commitment phase: Commit message broadcast: After receiving a sufficient number of prepare messages, the node generates and broadcasts a commit message; Transaction confirmation: After receiving at least 2f+12f+12f+1 commit messages, the node confirms the transaction and writes it to the local log or block;

[0030] (5) Reply phase: Transaction completion: After the transaction is written into the block, the node sends a confirmation message to the client; the confirmation information includes the final status of the transaction (success or failure) and its location.

[0031] Preferably, in step S4, the smart contract includes the following steps:

[0032] S41. Design and deployment of smart contracts; S42. Automated execution of device authentication; S43. Detection and response to abnormal behavior; S44. Feedback and storage of authentication results.

[0033] In the second aspect, the present invention also provides a system for implementing security authentication of Internet of Things devices based on blockchain technology, characterized in that it includes: a device registration module, an identity authentication module, a blockchain storage module, and a smart contract module. The device registration module is used to generate a unique identifier for each Internet of Things device on the blockchain, and store its basic information and authentication information in the blockchain; the identity authentication module is used to verify the authenticity of the device identity through the blockchain when the device is connected to the Internet of Things network; the blockchain storage module utilizes the distributed ledger technology of the blockchain to securely store the device's identity authentication information to ensure that the information cannot be tampered with; the smart contract module is responsible for automating the device identity authentication process to ensure the transparency and efficiency of the authentication process.

[0034] By adopting the above technical solution, the present invention has the following beneficial effects:

[0035] 1.Technological advantages

[0036] High degree of automation: The present invention realizes the automatic execution of device authentication through smart contracts, which greatly reduces human intervention. This automated processing not only improves the efficiency of authentication, but also reduces the possibility of human error, ensuring the consistency and reliability of the system.

[0037] Real-time monitoring and rapid response: The present invention uses smart contracts to monitor abnormal behavior during device authentication in real time, and can immediately trigger alarms and record logs when abnormalities are detected. Compared with traditional manual monitoring methods, the present invention can provide more timely responses and improve the security protection capabilities of the system.

[0038] Data immutability and transparency: The present invention records all authentication requests and results through blockchain technology, ensuring data immutability and traceability. This provides a reliable data basis for security audits and problem analysis, and improves the transparency of the system.

[0039] Decentralized trust mechanism: This invention utilizes the decentralized nature of blockchain to eliminate reliance on centralized servers and reduce the risk of single point failure. This trust mechanism improves the robustness and security of the system.

[0040] 2. Economic Effect

[0041] Reduced operation and maintenance costs: Since the present invention greatly improves the automation level of equipment authentication, it reduces the need for manual operation and maintenance, thereby reducing the operation and maintenance costs of the system. Enterprises can obtain more efficient authentication management with lower investment.

[0042] Improve production efficiency: Automation and real-time feedback mechanisms speed up the process of device access and certification, improving production efficiency. This enables companies to respond to market demands more quickly and shorten product launch time.

[0043] Reducing economic losses caused by errors: With the automation and accuracy of smart contracts, the present invention reduces authentication errors caused by human operational errors, thereby reducing related economic losses and subsequent repair costs.

[0044] 3. Social Effect

[0045] Improve information security level: The present invention enhances the security protection capability of information systems through reliable device authentication and real-time monitoring, helping enterprises to better protect user data and privacy.

[0046] Promote the application and popularization of blockchain technology: By applying blockchain technology to the field of device authentication, this invention promotes the application of blockchain technology in more industries and promotes its popularization and recognition in society.

[0047] Enhance user trust: The transparency of the system and the immutability of data enhance user trust in the system, improve user satisfaction and loyalty, which has a positive effect on the company's brand image. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] In order to more clearly illustrate the specific implementation methods of the present invention or the technical solutions in the prior art, the drawings required for use in the specific implementation methods or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some implementation methods of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0049] Figure 1 A schematic diagram of a framework of a method for implementing security authentication of an Internet of Things device based on blockchain technology provided by an embodiment of the present invention;

[0050] Figure 2 A data processing flow chart of IoT device authentication information provided by an embodiment of the present invention;

[0051] Figure 3 This is a PBFT consensus flow chart provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0052] The technical solution of the present invention will be described clearly and completely below in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0053] Embodiment 1

[0054] like Figures 1 to 3As shown, this embodiment 1 provides a method for implementing IoT device security authentication based on blockchain technology, which includes the following steps:

[0055] S1. Device registration: Generate a unique identifier for each IoT device on the blockchain, and store its basic information and authentication information on the blockchain; the device registration module is an important part of the present invention, which aims to provide a unique and secure identification and authentication mechanism for each newly connected device. The specific implementation process is as follows:

[0056] S11. Device Identifier Generation

[0057] S111. Physical feature collection: The device registration module first collects physical features from the device, the most commonly used feature of which is the device's MAC address (Media Access Control Address). The MAC address is a unique identifier for a hardware device, unique globally, and usually assigned by the device manufacturer. Using the MAC address helps ensure the uniqueness of each device in the network.

[0058] S112, Random number generation: To further enhance the uniqueness and security of the device identifier, the system uses a pseudo-random number generator (PRNG) to generate a random number This random number is combined with the device's MAC address to form a complex identifier, which increases the unpredictability of the identifier and prevents duplication or conflict.

[0059] S113. Identifier format: The generated device identifier is usually in UUID (Universally Unique Identifier) ​​format. UUID is a standardized identifier format, a string of 32 characters, usually displayed in the format of 8-4-4-4-12, such as 123e4567-e89b-12d3-a456-426614174000. UUID is designed to ensure uniqueness in different environments and systems.

[0060] S114. The formula for generating Device ID is as follows: Device ID = ℎMAC Address⊕Random Number

[0061] in, Represents a bitwise exclusive OR operation, Represents a generated random number. The above steps enable the IoT device to obtain a globally unique Device ID during the registration process, ensuring identification and management in the IoT network. This identifier generation method combines the hardware characteristics of the device with randomness, ensuring the uniqueness, unpredictability and security of the identifier.

[0062] S12, key pair generation: S121, encryption algorithm

[0063] Elliptic Curve Cryptography (ECC):

[0064] ECC is a modern public key encryption algorithm that provides high security with its shorter key length and is particularly suitable for IoT devices with limited resources.

[0065] The security of ECC is based on the elliptic curve discrete logarithm problem. It requires a shorter key length than the traditional RSA algorithm to provide the same security, so it is faster to calculate and suitable for implementation on IoT devices.

[0066] S122, private key generation

[0067] Random number generation:

[0068] Generate a private key d using a Cryptographically Secure Pseudo-RandomNumber Generator (CSPRNG).

[0069] Security requirements: The private key must be a large integer, and the generation process must ensure randomness and unpredictability to prevent it from being guessed by attackers.

[0070] Private Key Management:

[0071] The private key is the core credential of the device's identity and must be securely stored by the device to prevent it from being leaked.

[0072] Use secure hardware modules (HSMs) to store private keys, ensuring they cannot be stolen by malware or physical attacks.

[0073] Example: The private key generated by device Sensor-X is d = 0xA5B9C6D7E8F1, which is generated by CSPRNG to ensure its security.

[0074] S123, public key calculation

[0075] Elliptic curve base point:

[0076] The public key is calculated using a pre-selected elliptic curve base point G. The base point is a fixed parameter of the algorithm and a standardized elliptic curve, such as secp256k1, is usually used.

[0077] Public key calculation formula:

[0078] The public key Q is calculated from the private key d and the base point G:

[0079] in, is the public key, is the private key, is the base point of the elliptic curve.

[0080] Public key format: Public keys are usually expressed in compressed or uncompressed form, containing the coordinates of the points on the curve. Uncompressed public keys consist of a prefix (such as 0x04) plus the x and y coordinates.

[0081] Example: The public key Q of device Sensor-X is calculated as Q = 04A34F...8B7C, expressed in uncompressed format.

[0082] S124. Use of key pair

[0083] Purpose of public key: The public key is used for device authentication and can be made public securely for secure communication with other nodes in the network.

[0084] Purpose of private key: Private key is used to sign data packets and authentication requests to ensure the authenticity and integrity of messages.

[0085] Private keys should never be transmitted or exposed over the network and are only used for internal device operations.

[0086] S13. Prepare registration information

[0087] During the device registration process, preparing registration information is an important step to ensure that the device can be successfully registered on the blockchain. The registration information contains the basic identity of the device and the public key for authentication.

[0088] S131. Collect registration information

[0089] Device identification information: Unique identifier (UID): used to uniquely identify a device. The UID is generated through the device's hardware characteristics (such as MAC address) and random numbers to ensure its uniqueness and unpredictability.

[0090] Public key: The public key is used for device identity authentication and is part of the key pair generated by the device. The public key is calculated through ECC and is the public identity of the device in the network.

[0091] Example: The public key of device Sensor-X is Q = 04A34F...8B7C.

[0092] S132, structured registration information

[0093] Information formatting: Format the collected UIDs and public keys into structured data packets for easy transmission in the network and smart contract processing. The data packets use a standardized format to ensure compatibility between different devices and network nodes.

[0094] Data packet example: Registration information is usually expressed in JSON or other lightweight formats for easy parsing:

[0095] {

[0096] "UID": "SHA256_HASH",

[0097] "PublicKey": "04A34F...8B7C"

[0098] }

[0099] S14. Registration via smart contract

[0100] Smart contracts are self-executing programs on the blockchain that manage and verify the device registration process. Through smart contracts, devices can securely register their identity information on the blockchain and obtain decentralized authentication support. The registration process is as follows:

[0101] S141. Smart Contract Deployment

[0102] Contract design: The smart contract is designed to receive device registration requests, verify the integrity and legitimacy of the data packet, and store the registration information on the blockchain. The contract defines the logical rules and processes for device registration, including how to handle registration requests, verify signatures, check uniqueness, etc.

[0103] Contract deployment: The contract is deployed to the blockchain network, usually by the system administrator or developer. Once deployed, the contract address will be broadcast to the network for devices to send registration requests.

[0104] S142, registration request sent

[0105] Request build: The device builds a registration request, including its unique identifier (UID), public key, and signature.

[0106] Example:

[0107] json

[0108] {"UID": "d7c7e0d...9f3b9","PublicKey": "04A34F...8B7C","Signature": "3045022100c9..."}

[0109] Request sending: The device sends the registration request to the blockchain network where the smart contract is located through a secure communication channel. The communication protocol uses HTTPS to ensure secure data transmission.

[0110] S143. Contract Processing Flow

[0111] Signature verification: The contract first verifies the signature in the request to ensure that the request is indeed made by the claimed device. The signature is verified using the device's public key to check whether the signature matches the packet content.

[0112] Uniqueness check: The contract checks whether the same UID or public key already exists on the blockchain. If a duplication is detected, the contract will reject the registration request and record the reason for the failure.

[0113] Data storage: After verification, the contract stores the device's UID and public key on the blockchain. The registration information is recorded as part of the blockchain to ensure that the data cannot be tampered with.

[0114] S144, Feedback and Confirmation

[0115] Registration confirmation: After the contract is successfully executed, a transaction record is generated, which contains the registration information and transaction hash. The device receives the transaction hash as confirmation of successful registration.

[0116] Logging: The device records registration confirmation information (such as transaction hash and timestamp) in a local log to facilitate subsequent authentication and auditing.

[0117] Example:

[0118] After the device Sensor-X is successfully registered, it receives the transaction hash 0x1234abc... and records the information.

[0119] The device Sensor-X is successfully registered in the blockchain network, ensuring the uniqueness and security of its identity, laying the foundation for subsequent authentication and communication. Since the authentication information of the device is stored in the blockchain, its security and immutability are guaranteed, enhancing the overall security and reliability of the IoT system.

[0120] S2. Authentication: When a device accesses the IoT network, the authenticity of the device identity is verified through the blockchain; Authentication is a key step to ensure that IoT devices have a legitimate identity when accessing the network. Through the authentication information on the blockchain, the system can effectively verify the identity of the device and grant it network access rights.

[0121] S21, verification request initiated

[0122] Device access request: When a device attempts to access the IoT network, it sends an access request, including its DeviceID and public key. The device sends the request through a secure communication channel (HTTPS) to ensure that the data remains confidential and intact during transmission.

[0123] Authentication module starts: The authentication module in the network receives the access request from the device and prepares to perform authentication.

[0124] S22. Query blockchain authentication information

[0125] Device ID query:

[0126] The verification module queries the device’s authentication information on the blockchain through its Device ID. The Device ID corresponds to the device’s unique identifier (UID).

[0127] The blockchain query returns authentication information associated with the Device ID, including the device's public key and registration record.

[0128] Authentication information verification:

[0129] The verification module checks the integrity and legitimacy of the returned authentication information to ensure that the query results have not been tampered with.

[0130] S23. Authentication information comparison

[0131] Public key comparison:

[0132] The verification module compares the public key provided by the device with the public key stored on the blockchain.

[0133] The comparison method involves checking the hash values ​​of the public keys to ensure that the identity claimed by the device matches the identity when it was registered.

[0134] Verification results:

[0135] If the public key comparison is successful, the identity verification module confirms the legitimacy of the device identity.

[0136] S24. Granting network access permission

[0137] Permissions granted:

[0138] After verification, the device obtains permission to access the IoT network.

[0139] Network configuration includes assigning IP addresses, opening specific network service access permissions, etc.

[0140] Security policy application:

[0141] Based on the device type and authentication results, apply appropriate security policies and access controls.

[0142] S25. Recording of certification activities

[0143] Generate authentication record:

[0144] After the verification is successful, a new authentication record is generated, including the device ID, authentication timestamp, and verification result.

[0145] Record on chain:

[0146] The authentication record is stored in the blockchain as an unalterable log of the authentication activity.

[0147] The process of uploading certification records to the chain is automatically executed through smart contracts to ensure the transparency and credibility of the records.

[0148] Example record:

[0149] Example of a record generated after successful authentication of the device Sensor-X:

[0150] json

[0151] {"DeviceID": "d7c7e0d...9f3b9","Timestamp": "2024-08-14T10:15:00Z","Status": "Authenticated","TransactionHash": "0x9abcd..."}

[0152] S26. Example of authentication process

[0153] Device Sensor-X certification process:

[0154] Sensor-X sends an access request, including the Device ID and public key.

[0155] The authentication module queries the blockchain to retrieve the authentication information of Sensor-X.

[0156] The verification module compares the public key provided by the device with the public key on the blockchain.

[0157] After the signature verification is passed, the Sensor-X is granted network access permission.

[0158] Record certification activities and put certification records on the chain.

[0159] The present invention ensures that IoT devices can perform reliable identity authentication through blockchain when accessing the network. This process utilizes the decentralization and immutability of blockchain to ensure the security and transparency of device authentication information.

[0160] S3. Blockchain storage: Utilize the distributed ledger technology of blockchain to securely store the identity authentication information of the device to ensure that the information cannot be tampered with; blockchain storage plays an important role in the authentication process of IoT devices. Through the hybrid chain architecture, it can not only ensure the security and transparency of data, but also increase transaction speed and reduce storage costs.

[0161] S31. Hybrid chain architecture

[0162] The hybrid chain architecture combines the advantages of public and private chains, and achieves secure storage and management of IoT device authentication information through flexible data management and efficient transaction processing.

[0163] 1. Overview of hybrid chain architecture

[0164] The hybrid chain architecture is a blockchain system that combines the characteristics of public chains and private chains, achieving optimal performance, security, and cost-effectiveness by separating different types of data.

[0165] structure:

[0166] Public chain part: open to all network participants, suitable for storing data that needs to be publicly accessible, such as audit records and important event logs.

[0167] Private chain part: open only to authorized nodes, used to store sensitive information and perform high-frequency transaction processing, such as device authentication information.

[0168] 2. Characteristics of public and private chains

[0169] Public Blockchain:

[0170] Openness: Anyone can participate in the network, view and verify data.

[0171] Transparency: All transaction records are public, providing complete auditability.

[0172] Consensus mechanism: Proof of Work (PoW) or Proof of Stake (PoS) is usually used, which has high security but relatively slow transaction speed.

[0173] Private Blockchain:

[0174] Efficiency: Fast transaction processing and confirmation can be achieved by limiting node participation and optimizing consensus algorithms (such as PBFT and Raft).

[0175] Security: Access is limited to authenticated nodes only, protecting sensitive data.

[0176] Cost-effectiveness: Reduce operating costs by reducing participating nodes and simplifying storage strategies.

[0177] Implementation of hybrid chain architecture

[0178] 1. Tiered storage

[0179] The hybrid chain architecture stores data in layers according to sensitivity and access requirements. Data layered storage is one of the core strategies of the hybrid chain architecture. It allocates data storage locations according to data sensitivity and access requirements to maximize the different advantages of public and private chains. According to the sensitivity and access requirements of the data, the data is stored in the public chain and private chain respectively. The private chain is used to store sensitive information, such as device authentication data and status updates, to ensure data privacy and security. The public chain is used to store data that requires transparency, such as audit logs and event notifications, to ensure the openness and verifiability of the data.

[0180] (1) Private chain storage:

[0181] Among them, the data type

[0182] Device authentication information: including sensitive information such as the device's unique identifier (UID), public key, private key hash, etc. Status update: real-time status information of the device and internal configuration update records.

[0183] Among them, purpose and advantages

[0184] Privacy protection: Private chains restrict access rights and only allow authorized nodes to access, preventing sensitive data from being leaked. Security: Through node authentication and encryption technology, the security of data in transmission and storage is ensured. Efficiency improvement: The fast consensus algorithm Raft is used to increase transaction processing speed and adapt to high-frequency authentication needs.

[0185] (2) Public chain storage:

[0186] Among them, the data type is:

[0187] Authentication log: A record of successful or failed device authentication, including timestamp, device ID, and authentication result. Event notification: Announcements of important security events and system updates, accessible to all network participants.

[0188] Among them, the purpose and advantages:

[0189] Transparency: All participants can view and provide complete auditability. Credibility: Utilize the decentralized characteristics of the public chain to ensure that the data cannot be tampered with. Public access: Support external audits and compliance checks to enhance the credibility of the system.

[0190] 2. Implementation process:

[0191] (1) Data classification and labeling

[0192] Data classification: All data is divided into two categories: sensitive data and public data.

[0193] Sensitive data: including device authentication information, private key hashes, real-time status updates, etc.

[0194] Public data: including authentication logs, event notifications, and system announcements.

[0195] Data labeling: Assign specific labels or metadata to each type of data so that the appropriate chain can be automatically selected when storing it.

[0196] For example, sensitive data is marked as "P (Private)" and public data is marked as "PU (Public)".

[0197] (2) Data storage decision

[0198] Storage decision engine: Determines the data storage location (public chain or private chain) based on the data label and classification.

[0199] For example, device authentication information will be automatically identified as sensitive data and stored in a private chain.

[0200] Policy execution: Data is transferred to the corresponding blockchain according to the predefined storage policy. The storage policy is set by the system administrator and can be adjusted according to business needs.

[0201] (3) Data on-chain

[0202] Private chain on-chain: Sensitive data is stored in the private chain after encryption. The fast consensus mechanism PBFT is used to ensure low latency and high throughput of transactions.

[0203] Public blockchain: Store public data on the public blockchain, using the slower but more secure consensus mechanism PoW to ensure the authenticity and auditability of all public data.

[0204] S32. Data access control

[0205] Data access control is a key mechanism to ensure data security and privacy in the hybrid chain architecture. Through different access rights management strategies, the system can effectively protect sensitive information while providing the necessary transparency.

[0206] 1. Private chain access control

[0207] Among them, permission management:

[0208] Access Control List (ACL): defines which users or nodes have access rights. Through ACL, the system can set specific access rights for each data item or transaction.

[0209] Role-based Authority Control (RBAC): Assign permissions based on roles rather than individuals, making management more flexible and easy to expand.

[0210] Example roles:

[0211] Administrator: Has all permissions and can view, modify, and delete data.

[0212] Device management node: Able to view and update device status.

[0213] Auditor: Can view all authentication logs and event records.

[0214] Among them, authentication and authorization:

[0215] Nodes are authenticated using cryptographic certificates (X.509 certificates), ensuring that only authenticated nodes can participate in the network.

[0216] The encryption mechanism based on public and private key pairs ensures that data cannot be tampered with or eavesdropped during transmission.

[0217] Among them, data encryption:

[0218] Data stored on the private chain is encrypted to prevent unauthorized access.

[0219] Use symmetric encryption (AES) to protect data at rest and asymmetric encryption (RSA) to protect data in transit.

[0220] 2. Public chain access is open

[0221] Among them, open access:

[0222] The data of the public chain is open to all participants, and any node can join the network to view and verify the data. It provides complete transparency and auditability, and enhances the credibility of the system.

[0223] Among them, data verification: using the public chain consensus mechanism PoW to ensure the authenticity and immutability of data records. All transactions and event records can be independently verified and traced through the public chain.

[0224] 3. Security measures and technologies

[0225] Among them, encrypted communication: Use TLS protocol to ensure the security of communication between nodes, prevent middleman attacks and data interception. All sensitive information is encrypted before transmission.

[0226] Among them, logging and monitoring: real-time monitoring of access logs and data change records to detect abnormal behavior and potential security threats. Regularly review access control policies to ensure that they meet current security requirements and business needs.

[0227] Among them, permission change management: the addition or deletion of permissions must go through a strict approval process to ensure that changes in access control are intentional and safe. All permission changes are logged for easy auditing and backtracking.

[0228] The hybrid chain architecture can effectively protect the security of sensitive information while providing the necessary transparency and auditing capabilities for external participants. This architectural design enables the IoT device authentication system to maintain security and efficiency in different application scenarios.

[0229] S33. Device authentication information is stored in a private chain

[0230] In the IoT device authentication process, the device authentication information is stored in the private chain through a series of optimized technical means to achieve data security, privacy and efficiency. The following is a detailed implementation process:

[0231] 1. Device authentication information encryption

[0232] Among other things, information is collected and marked:

[0233] Collects authentication information of the device, including unique identifier (UID), public key, and authentication status.

[0234] This information is marked as sensitive data and needs to be encrypted to ensure privacy.

[0235] Among them, symmetric encryption is used:

[0236] Authentication information is encrypted using the Advanced Encryption Standard (AES-256).

[0237] The encryption process utilizes secure keys generated by the device management node, ensuring that the keys are only shared between authorized nodes.

[0238] The encrypted data becomes ciphertext to prevent unauthorized access.

[0239] 2. Generate timestamp and transaction ID

[0240] Generate timestamp: Get the current UTC time of the system and generate a timestamp in a standard format (such as ISO 8601) to mark the creation time of the data. Record the current timestamp to ensure the time consistency of data records.

[0241] Among them, generate transaction ID: use SHA-256 hash algorithm to generate transaction ID, combined with timestamp, device ID and random number to ensure the uniqueness of ID.

[0242] The transaction ID format is like 9f1c6a78d4e345e09d4..., which provides a unique identifier for each transaction to support traceability.

[0243] 3. Data Packaging and Formatting

[0244] Among them, the data formatting is:

[0245] Organize the encrypted data, timestamp and transaction ID into a data packet that complies with the private chain protocol.

[0246] Use JSON format to encapsulate data, making it easy to process and transmit.

[0247] The packet structure includes encrypted data, metadata, timestamp, and transaction ID.

[0248] Example packet structure:

[0249] json

[0250] {"transaction_id": "9f1c6a78d4e345e09d4...","timestamp": "2024-08-14T10:30:00Z","data": {"encrypted_info": "3b7d6e98f8...","metadata": {"encryption_algo": "AES-256","data_type": "DeviceAuth"}}}

[0251] Metadata description:

[0252] The metadata field records the encryption algorithm (AES-256) and data type (DeviceAuth), providing the necessary context information for data decryption and processing.

[0253] 4. Data on-chain and storage

[0254] ①Transaction generation and signature

[0255] Data Packet Preparation:

[0256] After collecting and encrypting the device authentication information, a data packet is generated containing the encrypted data, a timestamp, and a transaction ID.

[0257] The data packet structure is as follows:

[0258] json

[0259] {"transaction_id": "9f1c6a78d4e345e09d4...","timestamp": "2024-08-14T10:30:00Z","data": {"encrypted_info": "3b7d6e98f8...","metadata": {"encryption_algo": "AES-256","data_type": "DeviceAuth"}}}

[0260] Digital Signature:

[0261] The device management node digitally signs the data packet using its private key.

[0262] The signing process uses the asymmetric encryption algorithm ECDSA to ensure the uniqueness and security of the signature.

[0263] The signature is attached to the data packet, ensuring the authenticity of its origin and preventing the data from being tampered with in transit.

[0264] Signature Verification:

[0265] When other nodes receive a transaction, they use the public key of the management node to verify the validity of the signature.

[0266] Confirm that the data packet is indeed from a legitimate device management node to ensure data integrity.

[0267] ②Consensus mechanism confirmation

[0268] Consensus mechanism selection:

[0269] Choose a consensus algorithm suitable for private chains, PBFT (Practical Byzantine Fault Tolerance). PBFT is a consensus algorithm for distributed systems that can ensure that the system can reach consistency in the presence of Byzantine faults (i.e., nodes may fail in any way, including malicious behavior). The algorithm provides fast transaction confirmation and efficient network performance, and is suitable for high-frequency trading environments.

[0270] Transaction Broadcast:

[0271] The signed transaction data packet is broadcast to all participating private chain nodes.

[0272] After receiving the transaction, each node verifies the signature and checks the validity of the transaction.

[0273] Consensus process:

[0274] (1) Request phase:

[0275] Client sends request: The client initiates a transaction request and sends the request to the leader node (Primary).

[0276] Transaction content: The request includes transaction data, such as an encrypted package of device authentication information.

[0277] (2) Pre-prepare:

[0278] Leader node receives request: After receiving the client request, the leader node generates a pre-prepare message.

[0279] Message broadcast: The leader node broadcasts the prepared message to all replica nodes (Replicas).

[0280] Pre-prepare message content: including the requested sequence number, transaction content and leader node signature.

[0281] (3) Preparation stage:

[0282] Replica node verification: Each replica node verifies the legitimacy of the pre-prepared message, including verifying the signature and sequence number of the transaction.

[0283] Prepare message: If the verification passes, the replica node generates a prepare message and broadcasts it to all other nodes.

[0284] Confirm preparation: After receiving at least 2f+12f + 12f+1 prepare messages, the node enters the next stage.

[0285] (4) Commit:

[0286] Commit message broadcast: After a node receives a sufficient number of prepare messages, it generates a commit message and broadcasts it.

[0287] Transaction confirmation: After receiving at least 2f+12f + 12f+1 commit messages, the node confirms the transaction and writes it to the local log or block.

[0288] (5) Reply stage:

[0289] Transaction completed: After the transaction is written into the block, the node sends a confirmation message to the client.

[0290] Confirmation information: Contains the final status of the transaction (success or failure) and its location.

[0291] Transaction confirmation:

[0292] Once consensus is reached, the transaction is marked as confirmed, allowing it to be written to the blockchain.

[0293] The efficiency of the consensus algorithm ensures that transactions are confirmed within seconds, meeting the needs of real-time authentication of IoT devices.

[0294] The PBFT consensus process ensures that the system can process device authentication transactions quickly and efficiently, and ensures the security and consistency of the entire network even in the event of partial node failure. This mechanism provides a solid consensus guarantee for the private chain environment, making it very suitable for high-frequency authentication and data management of IoT devices.

[0295] ③Data storage

[0296] Block generation:

[0297] Confirmed transactions are packaged into blocks and prepared for storage in the private chain.

[0298] A block contains multiple transaction records and the hash value of the previous block, forming a blockchain structure.

[0299] Block write:

[0300] The newly generated blocks are written into the private chain, and each node will synchronously update the blockchain copy.

[0301] The data in the block is linked to the previous block through a hash pointer to ensure that the data cannot be tampered with.

[0302] Data Synchronization:

[0303] All participating nodes synchronize the latest block information through peer-to-peer network protocols (such as the Gossip protocol).

[0304] Ensure that each node has the same blockchain state to achieve data consistency and integrity.

[0305] Data persistence:

[0306] Transactions are permanently recorded in the blockchain, ensuring their durability and auditability.

[0307] The data persistence mechanism relies on the distributed storage characteristics of the blockchain, so that a single node failure will not lead to data loss.

[0308] S4. Smart Contract: Responsible for automating the device authentication process and ensuring the transparency and efficiency of the authentication process. Smart contracts are self-executing programs running on the blockchain that are used to automatically execute and verify predetermined agreement terms. They are stored on the blockchain in the form of code and can be automatically executed when specific conditions are met. Smart contracts make the device authentication process automated, standardized, and efficient, improving the security and management level of the entire system. The following are the characteristics of smart contracts:

[0309] Self-executing and immutable:

[0310] Self-execution: Smart contracts implement business logic that is automatically executed through coding, without the need for human intervention. Once the rules and conditions defined in the contract are triggered, the corresponding operations will be automatically executed.

[0311] Immutability: Smart contracts are deployed on the blockchain, and their contents cannot be modified once they are created. This ensures the transparency and credibility of contract execution.

[0312] Decentralized and distributed features:

[0313] Decentralization: Smart contracts run on the blockchain and do not rely on centralized servers. This makes the execution of contracts unaffected by single points of failure or centralized management.

[0314] Distributed ledger: All participating nodes hold the same copy of the ledger, and the execution results of the contract can be verified in the network, thus ensuring the integrity and consistency of the data.

[0315] In this invention, smart contracts are mainly used for automated control of device authentication, and the implementation process is as follows:

[0316] S41. Design and deployment of smart contracts

[0317] 1. Rule Definition

[0318] Equipment certification requirements analysis:

[0319] Device authentication: Determine a unique identifier for each device and develop a verification mechanism to ensure that only authenticated devices can access the system. This may involve public key encryption, digital signatures, or other authentication methods.

[0320] Permission allocation: Define the permission levels for different types of devices. According to the function and security requirements of the device, assign corresponding permissions to it to control its scope of operation in the system.

[0321] Anomaly detection: Establish detection rules for abnormal behavior, such as frequent authentication failures, suspicious access patterns, etc. Clarify the actions to be taken when anomalies are detected (logging, triggering alarms, etc.).

[0322] 2. Contract Development

[0323] Use Solidity language to write contracts:

[0324] Environment preparation: Select Remix for deployment, which is used to write and test Solidity code.

[0325] Contract structure design: According to the rule definition, the basic structure of the smart contract is constructed, including the state variables, function interfaces and events of the contract, so as to realize the complete logic of device authentication.

[0326] State variables: used to store data such as device information, permission configuration, and authentication status.

[0327] Function interface: a functional module that implements identity authentication, permission checking, and exception handling. For example:

[0328] solidity

[0329] function authenticateDevice(address deviceAddress, bytes memorysignature) public returns (bool) {

[0330] / / Verify device identity and update status

[0331] }

[0332] function assignPermissions(address deviceAddress, uint permissions)public onlyOwner {

[0333] / / Assign device permissions

[0334] }

[0335] function logAbnormalActivity(address deviceAddress, string memoryactivity) internal {

[0336] / / Log unusual activity

[0337] }

[0338] Contract testing: During the development process, unit tests and integration tests are performed on the contracts to ensure that all functions are executed as expected. The device authentication process in different scenarios is simulated to verify the correctness and security of the contract.

[0339] 3. Contract deployment

[0340] Deploy to the Ethereum blockchain:

[0341] Select a network: Based on the application scenario, choose the appropriate Ethereum network for deployment (mainnet or testnet).

[0342] Deploy contracts: Deploy smart contracts to the Ethereum network through the Remix tool to ensure the storage and execution of contracts on the blockchain.

[0343] Get the contract address and interface: After successful deployment, get the address and ABI (application binary interface) of the smart contract for subsequent authentication process calls. This information will serve as a key component in the system to connect the front-end application with the smart contract on the blockchain.

[0344] S42. Automated execution of device authentication

[0345] 1. Receipt of authentication request

[0346] Request receiving mechanism:

[0347] Device authentication request sending: When a device needs to access the system, it will send an authentication request. The request usually contains the device's identification information (such as device address), authentication credentials (such as digital signature), timestamp, etc.

[0348] Receiving and initializing smart contracts: Smart contracts are deployed on the blockchain and are responsible for listening to and receiving authentication requests from devices. Once a request is received, the smart contract extracts the information in the request and performs preliminary verification.

[0349] Request structure:

[0350] solidity

[0351] struct AuthRequest {

[0352] address deviceAddress;

[0353] bytes signature;

[0354] uint256 timestamp;

[0355] }

[0356] function receiveAuthRequest(AuthRequest memory request) public {

[0357] / / Initialize the authentication process

[0358] }

[0359] 2. Condition checking and execution

[0360] Condition check:

[0361] Authentication: The contract authenticates the request based on predefined rules. Common methods include public key verification, digital signature verification, etc. to ensure that the request is indeed from a legitimate device.

[0362] Digital signature verification: Use the device's public key to verify its signature to ensure that the request has not been tampered with.

[0363] solidity

[0364] function verifySignature(address deviceAddress, bytes memorysignature) internal view returns (bool) {

[0365] / / Verify signature logic

[0366] }

[0367] Permission check: After identity verification, the contract checks whether the device has the corresponding permission level to ensure that the device can only perform permitted operations.

[0368] Timestamp verification: Check the timestamp in the request to prevent replay attacks. Ensure that the request is processed within a valid time range by setting a reasonable time window.

[0369] Authorized Operations:

[0370] Condition satisfaction and authorization: If the device passes all verification conditions, the smart contract will perform the authorization operation and allow the device to access the system.

[0371] Status update: Update the authentication status of the device and record the device's access time and permissions.

[0372] solidity

[0373] function authorizeDevice(address deviceAddress) internal {

[0374] / / Update device status and grant access permission

[0375] }

[0376] Access Denied: If a device fails to meet any of the authentication conditions, the contract will deny access and may log the reason for failure for analysis.

[0377] S43. Detection and response to abnormal behavior

[0378] 1. Real-time monitoring

[0379] Implementation of monitoring mechanism:

[0380] Continuous behavior monitoring: During the device authentication process, the smart contract continuously monitors the device's behavior. The monitoring content includes the device's authentication request frequency, request failure times, and other suspicious operations.

[0381] Abnormal event detection: Set monitoring rules and thresholds to identify abnormal behavior. For example, multiple consecutive authentication failures or high-frequency authentication requests in a short period of time can be considered abnormal.

[0382] Monitoring rule example:

[0383] solidity

[0384] uint constant MAX_FAILED_ATTEMPTS = 3;

[0385] uint constant MIN_REQUEST_INTERVAL = 10 seconds;

[0386] mapping(address => uint) public failedAttempts;

[0387] mapping(address => uint) public lastRequestTime;

[0388] function monitorBehavior(address deviceAddress) internal returns(bool) {

[0389] if (failedAttempts[deviceAddress] > MAX_FAILED_ATTEMPTS) {

[0390] return true; / / Exception: Too many authentication failures

[0391] }

[0392] if (block.timestamp - lastRequestTime[deviceAddress] < MIN_REQUEST_INTERVAL) {

[0393] return true; / / Exception: Request frequency is too high

[0394] }

[0395] return false;

[0396] }

[0397] Dynamic adjustment: Dynamically adjust monitoring rules and thresholds based on actual system requirements and security situations to better adapt to different scenarios and threat models.

[0398] 2. Automatic alerts and logging

[0399] Alarm mechanism:

[0400] Real-time alarm triggering: When abnormal behavior is detected, the smart contract will immediately trigger an alarm. The alarm can be notified to the administrator through the blockchain network for a quick response.

[0401] Alarm example:

[0402] solidity

[0403] event Alert(address indexed deviceAddress, string message, uinttimestamp);

[0404] function triggerAlert(address deviceAddress, string memory message)internal {

[0405] emit Alert(deviceAddress, message, block.timestamp);

[0406] }

[0407] Multi-channel notification: In addition to event triggering on the blockchain, other notification mechanisms can also be integrated, such as email, SMS or system messages, to ensure that relevant personnel can obtain warning information in a timely manner.

[0408] Logging:

[0409] Event log storage: Smart contracts will record all abnormal behaviors in the blockchain, including the time when the abnormality occurred, device identification and specific behavior description.

[0410] Logging example:

[0411] solidity

[0412] struct AbnormalEvent {

[0413] address deviceAddress;

[0414] string behavior;

[0415] uint timestamp;

[0416] }

[0417] AbnormalEvent[] public abnormalEvents;

[0418] function recordAbnormalEvent(address deviceAddress, string memorybehavior) internal {

[0419] abnormalEvents.push(AbnormalEvent(deviceAddress, behavior,block.timestamp));

[0420] }

[0421] Unalterable audit trails: Since logs are recorded on the blockchain, their unalterable nature ensures the traceability of events. This is of great value for post-event analysis, compliance reviews, and security audits.

[0422] S44. Feedback and storage of authentication results

[0423] 1. Result feedback

[0424] Implementation of feedback mechanism:

[0425] Instant feedback: When the smart contract completes the device authentication process, it will immediately feedback the authentication results to the requesting device. The feedback information includes the authentication status (success or failure) and a description of the possible reasons.

[0426] Feedback process:

[0427] solidity

[0428] event AuthenticationResult(address indexed deviceAddress, boolsuccess, string message);

[0429] function sendFeedback(address deviceAddress, bool success, stringmemory message) internal {

[0430] emit AuthenticationResult(deviceAddress, success, message);

[0431] }

[0432] Device notification: Through the event mechanism defined in the contract, feedback information will be broadcast to all nodes in the blockchain network, and the device can listen and obtain the authentication results.

[0433] Detailed information provision: In the case of authentication failure, the feedback information can include detailed failure reasons to help the device to correct itself or the administrator to troubleshoot the problem.

[0434] Feedback example:

[0435] Authentication success: After the device successfully passes the identity authentication and obtains the permission, the smart contract sends feedback information to the device:

[0436] solidity

[0437] sendFeedback(deviceAddress, true, "Authentication Successful");

[0438] Authentication failed: If authentication fails, the feedback will include the specific reason for failure:

[0439] solidity

[0440] sendFeedback(deviceAddress, false, "Invalid Signature");

[0441] 2. Data Storage

[0442] Implementation of storage mechanism:

[0443] Blockchain records: The smart contract will record each authentication request and its results on the blockchain. These records include device address, request time, authentication status and related details.

[0444] Storage structure example:

[0445] solidity

[0446] struct AuthRecord {

[0447] address deviceAddress;

[0448] uint timestamp;

[0449] bool success;

[0450] string details;

[0451] }

[0452] AuthRecord[] public authHistory;

[0453] function recordAuthResult(address deviceAddress, bool success, stringmemory details) internal {

[0454] authHistory.push(AuthRecord(deviceAddress, block.timestamp,success, details));

[0455] }

[0456] Immutability: Since the data is stored on the blockchain, all authentication records are immutable, ensuring the integrity and credibility of the data.

[0457] Historical data access: The data recorded on the blockchain forms a complete authentication history, which can be used for subsequent security audits, analysis and report generation.

[0458] In summary, the innovations of this embodiment are embodied in the following aspects:

[0459] Introduction of hybrid chain architecture:

[0460] Traditional IoT device authentication systems rely on centralized authentication servers. This approach has the risk of single point failure, is vulnerable to attacks, and is difficult to ensure that data cannot be tampered with. The present invention innovatively adopts a hybrid chain architecture to store device authentication information in a private chain, while using the transparency of the public chain for auditing and recording. Through this architecture, the system not only eliminates the security risks of the centralized structure, but also improves data security and the overall reliability of the system through hierarchical storage and decentralized access, ensuring the non-tamperability and durability of device authentication information.

[0461] Efficient consensus mechanism:

[0462] In traditional IoT authentication systems, processing a large number of concurrent requests often leads to authentication delays, reducing system efficiency. The present invention adopts an efficient PBFT consensus algorithm, which significantly improves the speed of transaction confirmation. The PBFT algorithm ensures fast processing capabilities in high-frequency trading environments through multiple rounds of message transmission and rapid consensus, greatly reducing authentication delays. Compared with the prior art, the present invention can achieve fast transaction confirmation and data synchronization while ensuring security, thereby improving the response speed and practicality of the system.

[0463] Tiered storage and access control:

[0464] The IoT device authentication system in the prior art usually lacks flexible storage and access control mechanisms, which can easily lead to data leakage and management confusion. The present invention ensures that only authorized nodes can access sensitive information by storing data in layers according to its sensitivity and access requirements and implementing strict access control in the private chain. Combined with the public storage of audit records in the public chain, the present invention not only strengthens the privacy protection of data, but also enhances the manageability and trustworthiness of the system through a transparent audit path, thereby achieving highly secure and scalable IoT device authentication management.

[0465] Embodiment 2

[0466] like Figures 1 to 3 As shown, the second embodiment provides a system for realizing security authentication of IoT devices based on blockchain technology on the basis of the first embodiment. The second embodiment includes the technical content disclosed in the first embodiment. The technical content of the second embodiment that is the same as that of the first embodiment will not be repeated. The difference between the second embodiment and the first embodiment is described below, which includes: a device registration module, an identity authentication module, a blockchain storage module, and a smart contract module. The device registration module is used to generate a unique identifier for each IoT device on the blockchain, and store its basic information and authentication information in the blockchain; the identity authentication module is used to verify the authenticity of the device identity through the blockchain when the device is connected to the IoT network; the blockchain storage module uses the distributed ledger technology of the blockchain to securely store the identity authentication information of the device to ensure that the information cannot be tampered with; the smart contract module is responsible for automating the device identity authentication process to ensure the transparency and efficiency of the authentication process.

[0467] Embodiment 3

[0468] This embodiment 3 provides a specific application example based on the embodiments 1 and 2. This embodiment 3 includes the technical contents disclosed in the embodiment 1. The technical contents of this embodiment 3 that are the same as those of the embodiment 1 are not repeated here. The differences between this embodiment 3 and the embodiment 1 are described below.

[0469] This third embodiment provides an application of blockchain-based IoT device security authentication in smart city sensor networks.

[0470] 1. In a typical smart city environment, multiple sensor networks are deployed in different urban areas to monitor environmental parameters such as air quality, temperature, humidity, and noise level in real time. Each sensor device needs to be authenticated through blockchain technology to ensure the credibility of the data source and prevent the device from being tampered with or counterfeited. This embodiment describes the entire process of device registration, identity authentication, and authentication record storage of the sensor device Sensor-X in the smart city sensor network.

[0471] 2. Device Registration

[0472] 2.1 Device Identifier Generation

[0473] Sensor-X is an environmental monitoring sensor with a unique MAC address of 00:1A:C2:7B:00:47. During the device registration process, the device management node first collects the MAC address and uses a pseudo-random number generator (PRNG) to generate a random number 0x3F5A1B8C. The device identifier is generated using the following formula:

[0474] Device ID=ℎ MAC Address ⊕ Random Number

[0475] The calculated Device ID is c4d8e3a24c1b5e9f2a7d6b3a8f1b4c9d, which is in UUID format and remains unique across the entire smart city sensor network.

[0476] 2.2 Key Pair Generation

[0477] To ensure the data transmission security of Sensor-X, the system generates a pair of keys using the elliptic curve cryptography (ECC). The private key d = 0xA5B9C6D7E8F1 is generated by CSPRNG and stored in the device's secure hardware module HSM. The public key is calculated using the following formula:

[0478]

[0479] Where G is the base point of the elliptic curve secp256k1, and the calculated public key is Q = 04A34F6D7B89C8E1...8B7C. The public key is stored in an uncompressed format and will be made public during the device registration process.

[0480] 2.3 Prepare registration information

[0481] During the registration information preparation phase, Sensor-X’s unique identifier c4d8e3a24c1b5e9f2a7d6b3a8f1b4c9d and public key 04A34F6D7B89C8E1...8B7C are formatted as a JSON packet:

[0482] {

[0483] "UID": "c4d8e3a24c1b5e9f2a7d6b3a8f1b4c9d",

[0484] "PublicKey": "04A34F6D7B89C8E1...8B7C"

[0485] }

[0486] 2.4 Registration via Smart Contract

[0487] Sensor-X sends a registration request to the blockchain network. The request content is as follows:

[0488] {

[0489] "UID": "c4d8e3a24c1b5e9f2a7d6b3a8f1b4c9d",

[0490] "PublicKey": "04A34F6D7B89C8E1...8B7C",

[0491] "Signature": "3045022100c9..."

[0492] }

[0493] After receiving the request, the smart contract verifies the validity of the signature and checks the uniqueness of the UID and public key. After verification, the registration information of Sensor-X is stored in the private chain, and the transaction hash 0x1234abc... is returned as confirmation of successful registration. This information is also recorded in the local log of the device.

[0494] 3. Authentication

[0495] 3.1 Verification Request Initiation

[0496] When Sensor-X attempts to access the smart city sensor network, it sends the following authentication request:

[0497] {

[0498] "DeviceID": "c4d8e3a24c1b5e9f2a7d6b3a8f1b4c9d",

[0499] "PublicKey": "04A34F6D7B89C8E1...8B7C"

[0500] }

[0501] After receiving the request, the verification module queries the device authentication information through the blockchain and compares the provided public key with the public key stored on the blockchain.

[0502] 3.2 Authentication Information Verification and Authorization

[0503] After verification, the network assigns Sensor-X an IP address of 192.168.1.100 and grants it access to environmental monitoring data. At this point, Sensor-X can legally transmit data in the network and communicate securely with other nodes.

[0504] 3.3 Recording of certification activities

[0505] After successful authentication, the generated authentication record is as follows:

[0506] {

[0507] "DeviceID": "c4d8e3a24c1b5e9f2a7d6b3a8f1b4c9d",

[0508] "Timestamp": "2024-08-14T10:15:00Z",

[0509] "Status": "Authenticated",

[0510] "TransactionHash": "0x9abcd..."

[0511] }

[0512] The record is stored in the private chain part of the blockchain, ensuring the immutability and traceability of the authentication log.

[0513] 4. Blockchain Storage

[0514] 4.1 Implementation of hybrid chain architecture

[0515] During the authentication process of Sensor-X, the private chain is used to store sensitive data such as authentication information and status updates, while the public chain is used to record authentication logs and event notifications. The private chain uses the Raft consensus algorithm to ensure low latency and high throughput of transactions, while the public chain uses the PoW algorithm to ensure the openness and auditability of data.

[0516] 4.2 Data Storage and Access Control

[0517] All authentication information is encrypted with AES-256 and stored in the private chain, and ACL permissions are set to ensure that only authorized nodes can access these sensitive data. The authentication log is publicly stored in the public chain and can be accessed by any node to support external audits.

[0518] 5. Automated execution of smart contracts

[0519] 5.1 Automation of the certification process

[0520] After receiving the authentication request from Sensor-X, the smart contract automatically performs identity authentication, permission checking, and anomaly detection. Through the self-executing logic in the contract, the authentication process of Sensor-X is standardized and automated without manual intervention, ensuring the efficient operation of the system.

[0521] 5.2 Abnormal Behavior Detection and Logging

[0522] In actual operation, if Sensor-X fails authentication multiple times in a row, the smart contract will automatically trigger an alarm and record abnormal behavior logs for administrators to analyze and respond.

[0523] 5.3 Certification Result Feedback

[0524] Each authentication result, whether successful or failed, will be fed back to Sensor-X in real time and recorded on the blockchain. These records will serve as the audit basis of the system to ensure the transparency and credibility of the authentication process.

[0525] This embodiment shows in detail the application of the present invention in the smart city sensor network. Through the comprehensive application of device registration, identity authentication and blockchain storage, the security, reliability and traceability of sensor devices in the Internet of Things environment are ensured, providing a stable and efficient data monitoring solution for smart cities.

[0526] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for realizing security authentication of IoT devices based on blockchain technology, characterized in that: The steps include: S1. Device registration: Generate a unique identifier for each IoT device on the blockchain and store its basic information and authentication information in the blockchain; S2. Authentication: When a device is connected to the IoT network, the authenticity of the device identity is verified through the blockchain; S3, blockchain storage: Use blockchain's distributed ledger technology to securely store device identity authentication information to ensure that the information cannot be tampered with; S4, Smart Contract: Responsible for automating the device identity authentication process to ensure the transparency and efficiency of the authentication process.

2. The method for realizing security authentication of IoT devices based on blockchain technology according to claim 1 is characterized in that: In step S1, device registration, it includes the following steps: S11, generating a device identifier; S12, generating a key pair; S13. Prepare registration information; S14. Registration through smart contract.

3. The method for realizing security authentication of IoT devices based on blockchain technology according to claim 1 is characterized in that: In step S2 identity verification, it includes the following steps: S21, verification request initiated; S22. Query blockchain authentication information; S23, authentication information comparison; S24. Grant network access permission.

4. The method for realizing security authentication of IoT devices based on blockchain technology according to claim 1 is characterized in that: In step S3 blockchain storage, it includes the following steps: S31, hybrid chain architecture; S32, data access control; S33. Device authentication information is stored in a private chain.

5. The method for realizing security authentication of IoT devices based on blockchain technology according to claim 4 is characterized in that: In step S33, the device authentication information is stored in the private chain, which includes the following steps: S331, device authentication information encryption; Among them, collecting and marking information: collecting authentication information of the device, including unique identifier, public key and authentication status; Among them, symmetric encryption is used: the authentication information is encrypted using the AES-256 encryption algorithm. The encryption process uses security keys generated by the device management node to ensure that the keys are only shared between authorized nodes. The encrypted data becomes ciphertext to prevent unauthorized access. S332, generate a timestamp and a transaction ID; Among them, generate timestamp: obtain the current UTC time of the system, generate a timestamp in a standard format to mark the creation time of the data; record the current timestamp to ensure the time consistency of data records; Generate transaction ID: Generate transaction ID using SHA-256 hash algorithm, combine timestamp, device ID and random number to ensure the uniqueness of ID, and provide unique identification for each transaction to support traceability; S333, data packaging and formatting; Among them, data formatting: organize the encrypted data, timestamp and transaction ID into a data packet that complies with the private chain protocol; use JSON format to encapsulate the data to facilitate processing and transmission; the data packet structure includes encrypted data, metadata, timestamp and transaction ID; S334. Data on-chain and storage, including: transaction generation and signature, consensus mechanism confirmation, and data storage.

6. The method for realizing security authentication of IoT devices based on blockchain technology according to claim 5 is characterized in that: In step S334, the consensus mechanism confirms the selection of the consensus algorithm PBF suitable for the private chain, including: (1) Request phase: Among them, the client sends a request: the client initiates a transaction request and sends the request to the leader node; Among them, the client sends the transaction content: the request includes the transaction data; (2) Pre-preparation stage: Wherein, the leader node receives the request: after receiving the client request, the leader node generates a pre-prepare message; Among them, message broadcast: the leader node broadcasts the pre-prepared message to all replica nodes; Among them, the pre-prepared message content includes: the requested sequence number, transaction content and leader node signature; (3) Preparation stage: Among them, replica node verification: Each replica node verifies the legitimacy of the pre-prepared message, including verifying the signature and sequence number of the transaction; Among them, prepare message: If the verification passes, the replica node generates a prepare message and broadcasts it to all other nodes; Confirmation of preparation: After receiving at least 2f+12f + 12f+1 preparation messages, the node enters the next stage; (4) Submission stage: Among them, commit message broadcast: after receiving a sufficient number of prepare messages, the node generates a commit message and broadcasts it; Transaction confirmation: After receiving at least 2f+12f + 12f+1 commit messages, the node confirms the transaction and writes it to the local log or block; (5) Response stage: Among them, transaction completion: after the transaction is written into the block, the node sends a confirmation message to the client; Among them, confirmation information: contains the final status of the transaction (success or failure) and its location.

7. The method for realizing security authentication of IoT devices based on blockchain technology according to claim 1 is characterized in that: In step S4, the smart contract includes the following steps: S41. Design and deployment of smart contracts; S42, automated execution of equipment authentication; S43. Detection and response to abnormal behavior; S44. Feedback and storage of authentication results.

8. A system for realizing security authentication of IoT devices based on blockchain technology, characterized in that: include: Device registration module, identity authentication module, blockchain storage module, smart contract module. The device registration module is used to generate a unique identifier for each IoT device on the blockchain and store its basic information and authentication information in the blockchain. The identity authentication module is used to verify the authenticity of the device identity through the blockchain when the device is connected to the IoT network. The blockchain storage module uses the distributed ledger technology of the blockchain to securely store the device's identity authentication information to ensure that the information cannot be tampered with. The smart contract module is responsible for automating the device identity authentication process, ensuring the transparency and efficiency of the authentication process.

Images