A blockchain-based method and system for secure distribution of patches for internet of things

Abstract

The application discloses a kind of blockchain-based Internet of Things patch security distribution method and system, comprising: obtaining the basic information and identity information of equipment;Using vulnerability detection algorithm to detect whether the corresponding vulnerability information of basic information exists in known vulnerability database;If there is, obtain the virtual patch corresponding to vulnerability information from vulnerability patch database;According to the identity in identity information, verify whether identity information is valid;If valid, send virtual patch to equipment, so that equipment installs virtual patch;After the completion of virtual patch installation in equipment, simulate the attack behavior of equipment in isolated environment, and monitor whether equipment successfully blocks attack behavior;If equipment successfully blocks attack behavior, send virtual patch to similar equipment.Thereby, according to identity, each equipment is given unique and tamper-proof identity, effectively resist the attack to equipment identity, effectively solve the problem that equipment identity is difficult to authenticate.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) security technology, and in particular to a blockchain-based IoT patch security distribution method and system. Background Technology

[0002] With the widespread adoption of Internet of Things (IoT) devices, device security has become increasingly important. Due to limitations in hardware resources, the complexity of communication protocols, and variations in deployment environments, IoT devices often harbor numerous security vulnerabilities. These vulnerabilities can be exploited by attackers, leading to loss of control of devices, data breaches, or even large-scale attacks on the entire network.

[0003] To address this issue, virtual patching technology is employed. Specifically, virtual patching implements protection rules external to the device, rather than directly modifying the device's firmware, effectively blocking the exploit path. This approach is independent of manufacturer-released firmware updates, enabling rapid response to security threats and reducing the window of opportunity for vulnerability exploitation. Virtual patching typically utilizes network-level protection measures, such as firewalls and IDS / IPS (Intrusion Detection / Prevention Systems), to promptly intercept potential attack traffic and ensure the security of IoT devices.

[0004] While virtual patching technology has shown great potential in IoT security, current virtual patching mechanisms still have some key issues. Due to the sheer number and complexity of IoT devices, traditional authentication methods are ill-suited for large-scale deployments. This results in vulnerabilities in the authentication processes of many devices, allowing malicious devices to impersonate legitimate ones and receive virtual patches. Furthermore, this weakness in device authentication can lead to accidental patch distribution or incorrect deployment of protection rules, impacting overall security. Summary of the Invention

[0005] In view of the shortcomings of the existing technology, this application provides a blockchain-based IoT patch security distribution method and system to solve the problem of difficult device identity authentication.

[0006] To achieve the above objectives, this application provides the following technical solution:

[0007] The first aspect of this application provides a blockchain-based IoT patch distribution security method, including:

[0008] Obtain basic device information and identity information;

[0009] The vulnerability detection algorithm is used to check whether the vulnerability information corresponding to the basic information exists in the known vulnerability database.

[0010] If the known vulnerability database contains vulnerability information corresponding to the basic information, then the virtual patch corresponding to the vulnerability information is obtained from the vulnerability patch database;

[0011] Verify the validity of the identity information based on the identity identifier in the identity information;

[0012] If the identity information is valid, the virtual patch is sent to the device so that the device can install the virtual patch;

[0013] After the virtual patch is installed on the device, an attack is simulated on the device in an isolated environment, and the device is monitored to see if it successfully blocks the attack.

[0014] If the device successfully blocks the attack, the virtual patch is sent to a similar device; wherein, the similar device refers to a device of the same type as the device.

[0015] Optionally, in the above-described blockchain-based IoT patch security distribution method, verifying the validity of the identity information based on the identity identifier in the identity information includes:

[0016] Extract the device's identity identifier, binding information, and signature of verifiable credentials from the identity information;

[0017] Check whether the identity identifier has been registered on the blockchain and whether it is in a valid state;

[0018] If the identity identifier is registered on the blockchain and is in a valid state, then it is checked whether the identity identifier and the binding information are consistent with the information of the device recorded in the blockchain;

[0019] If the identity identifier and the binding information are consistent with the information of the device recorded in the blockchain, then the public key of the verifiable credential is extracted from the blockchain;

[0020] The signature is verified using the public key, and the identity information is determined to be valid when the signature passes verification.

[0021] Optionally, the above-described blockchain-based IoT patch security distribution method also includes:

[0022] Obtain the verification result of the identity information and the diffusion information of the virtual patch; wherein, the diffusion information refers to the information of sending the virtual patch to the similar devices;

[0023] The verification results and the dissemination information are stored in the blockchain.

[0024] Optionally, the above-described blockchain-based IoT patch security distribution method also includes:

[0025] Obtain the data packet sent by the sender; wherein the data packet includes at least virtual patch transaction bytes and its corresponding checksum;

[0026] Calculate the target verification value of the virtual patch transaction bytes, and determine whether the verification value is consistent with the target verification value;

[0027] If the verification value is inconsistent with the target verification value, the data packet will be dropped.

[0028] If the verification value matches the target verification value, the data packet is parsed to obtain parsed data, and based on the parsed data, the completeness of the virtual patch and its compatibility with the device are verified.

[0029] If the virtual patch is complete and matches the device, then multiple delay nodes are used to synchronize the virtual patch transaction bytes, and the virtual patch transaction bytes are fragmented to obtain multiple fragment nodes; wherein, the first fragment node carries the fragment sequence number and the total number of fragments;

[0030] Each of the fragment nodes is sent to the sender in sequence, so that the sender can reassemble the data according to each fragment node and record the acknowledgment signal of each fragment node;

[0031] Acquire multiple confirmation signals, and determine whether the sender has received all the shard nodes based on each confirmation signal;

[0032] If the sender receives all the shard nodes, it packages the virtual patch transaction bytes and stores the packaged virtual patch transaction bytes in the blockchain bytes;

[0033] If the sender does not receive all the fragment nodes, a retransmission mechanism is triggered.

[0034] Optionally, the above-described blockchain-based IoT patch security distribution method also includes:

[0035] The blockchain bytes are obtained and parsed to obtain target parsed data; wherein the target parsed data includes at least the hash value of the preceding block of the blockchain bytes;

[0036] Verify whether the hash value of the preceding block is consistent with the hash value of the current block in the local area, and whether the virtual patch transaction byte is in the block body of the blockchain;

[0037] If the hash value of the preceding block is consistent with the hash value of the current block in the local blockchain, and the virtual patch transaction byte is in the block body of the current block, then multiple seed nodes in the blockchain are used to synchronize the data in the block body; wherein, the seed node refers to a node in the blockchain whose storage space is greater than a preset threshold and whose online time is greater than a preset time.

[0038] After the synchronization process is completed, the synchronized data of each seed node is forwarded to the backbone node so that the backbone node forwards the synchronized data; wherein, the backbone node refers to a node with a bandwidth not less than a preset bandwidth threshold and that has passed node verification.

[0039] When the number of times the backbone node receives data reaches a preset number, the forwarding operation of the backbone node is stopped, and the association mapping table is updated according to the location information of the virtual patch transaction bytes and the block body.

[0040] Optionally, the above-described blockchain-based IoT patch security distribution method also includes:

[0041] When a monitoring instruction for the mainnet status is received, it is determined whether the core node has triggered a primary / backup switch; wherein, the core node refers to the node in the main network of the blockchain that is responsible for transaction processing and block propagation;

[0042] If the core node triggers a primary / backup switch, the data will stop being sent to the core node and will instead be sent to high-reputation nodes in the sentinel node list for propagation; wherein, the high-reputation node refers to a node whose forwarding success rate is greater than a preset threshold within a preset time period and whose offline time is not greater than a preset time.

[0043] After the propagation is complete, the core node is connected to the main network and the sentinel network respectively, and the hash value of the main network and the hash value of the sentinel network are obtained.

[0044] Compare whether the hash value of the main network and the hash value of the sentinel network are consistent;

[0045] If the hash value of the main network and the hash value of the sentinel network are inconsistent, the Merkle tree algorithm is used to locate the difference transaction and obtain the longest chain of the main network.

[0046] The local ledger is corrected based on the discrepancies in the transactions and the longest chain.

[0047] A second aspect of this application provides a blockchain-based IoT patch security distribution system, comprising:

[0048] The information acquisition unit is used to acquire basic information and identity information of the device.

[0049] The vulnerability detection unit is used to use vulnerability detection algorithms to detect whether the vulnerability information corresponding to the basic information exists in the known vulnerability database;

[0050] The patch acquisition unit is used to acquire a virtual patch corresponding to the vulnerability information from the vulnerability patch database if the vulnerability information corresponding to the basic information exists in the known vulnerability database.

[0051] An identity verification unit is used to verify whether the identity information is valid based on the identity identifier in the identity information;

[0052] A patch sending unit is configured to send the virtual patch to the device if the identity information is valid, so that the device can install the virtual patch;

[0053] The monitoring unit is used to simulate attack behavior on the device in an isolated environment after the virtual patch is installed on the device, and to monitor whether the device successfully blocks the attack behavior.

[0054] A patch distribution unit is configured to send the virtual patch to similar devices if the device successfully blocks the attack; wherein, the similar devices refer to devices of the same type as the device.

[0055] Optionally, in the aforementioned blockchain-based IoT patch security distribution system, the authentication unit includes:

[0056] The extraction unit is used to extract the device's identity identifier, binding information, and signature of verifiable credentials from the identity information;

[0057] The identifier detection unit is used to detect whether the identity identifier has been registered on the blockchain and whether it is in a valid state;

[0058] An information detection unit is used to detect whether the identity identifier and the binding information are consistent with the information of the device recorded in the blockchain if the identity identifier has been registered on the blockchain and is in a valid state.

[0059] A public key extraction unit is used to extract the public key of the verifiable credential from the blockchain if the identity identifier and the binding information are consistent with the information of the device recorded in the blockchain.

[0060] A signature verification unit is used to verify the signature using the public key, and when the signature passes verification, it determines that the identity information is valid.

[0061] Optionally, the aforementioned blockchain-based IoT patch security distribution system also includes:

[0062] The first acquisition unit is used to acquire the verification result of the identity information and the diffusion information of the virtual patch; wherein, the diffusion information refers to the information of sending the virtual patch to the similar devices;

[0063] A storage unit is used to store the verification results and the diffusion information into the blockchain.

[0064] Optionally, the aforementioned blockchain-based IoT patch security distribution system also includes:

[0065] The second acquisition unit is used to acquire data packets sent by the sender; wherein the data packets include at least virtual patch transaction bytes and their corresponding checksums;

[0066] The calculation unit is used to calculate the target verification value of the virtual patch transaction byte and determine whether the verification value is consistent with the target verification value.

[0067] The packet loss unit is used to drop the data packet if the check value is inconsistent with the target check value.

[0068] The verification unit is used to parse the data packet to obtain parsed data if the verification value is consistent with the target verification value, and to verify whether the virtual patch is complete and whether it matches the device based on the parsed data.

[0069] The first synchronization unit is configured to, if the virtual patch is complete and matches the device, use multiple delay nodes to synchronize the virtual patch transaction bytes and perform fragmentation processing on the virtual patch transaction bytes to obtain multiple fragmentation nodes; wherein, the first fragmentation node carries a fragmentation sequence number and a total number of fragments;

[0070] The reassembly unit is used to sequentially send each of the fragment nodes to the sender, so that the sender can reassemble the fragments according to each of the fragment nodes and record the acknowledgment signals of each of the fragment nodes.

[0071] A node determination unit is used to acquire multiple confirmation signals and determine, based on each confirmation signal, whether the sender has received all the fragment nodes.

[0072] The packaging unit is used to package the virtual patch transaction bytes if the sender receives all the shard nodes, and store the packaged virtual patch transaction bytes in the blockchain bytes;

[0073] The triggering unit is used to trigger a retransmission mechanism if the sender has not received all the fragment nodes.

[0074] Optionally, the aforementioned blockchain-based IoT patch security distribution system also includes:

[0075] The third acquisition unit is used to acquire the blockchain bytes and parse the blockchain bytes to obtain target parsed data; wherein the target parsed data includes at least the hash value of the preceding block of the blockchain bytes;

[0076] The verification unit is used to verify whether the hash value of the preceding block is consistent with the hash value of the current block in the local area, and whether the virtual patch transaction byte is in the block body of the blockchain.

[0077] The second synchronization unit is used to synchronize the data in the block body by using multiple seed nodes in the blockchain if the hash value of the preceding block is consistent with the hash value of the current block in the local blockchain, and the virtual patch transaction byte is in the block body of the current block; wherein, the seed node refers to a node in the blockchain whose storage space is greater than a preset threshold and whose online time is greater than a preset time.

[0078] The forwarding unit is used to forward the synchronized data of each seed node to the backbone node after the synchronization process is completed, so that the backbone node forwards the synchronized data; wherein, the backbone node refers to a node with a bandwidth not less than a preset bandwidth threshold and that has passed node verification.

[0079] The update unit is used to stop the forwarding operation of the backbone node when the number of times the backbone node receives data reaches a preset number, and update the association mapping table according to the location information of the virtual patch transaction bytes and the block body.

[0080] Optionally, the aforementioned blockchain-based IoT patch security distribution system also includes:

[0081] The judgment unit is used to determine whether the core node has triggered a primary / backup switch when it receives a monitoring instruction on the main network status; wherein, the core node refers to the node in the main network of the blockchain that is responsible for transaction processing and block propagation;

[0082] The stop unit is used to stop sending the data to the core node and send the data to a high-reputation node in the sentinel node list for propagation if the core node triggers a primary / backup switch. The high-reputation node refers to a node whose forwarding success rate is greater than a preset threshold and whose offline time is not greater than a preset time during a preset period.

[0083] The connection unit is used to connect the core node to the main network and the sentinel network respectively after the propagation is completed, and to obtain the hash value of the main network and the hash value of the sentinel network.

[0084] The comparison unit is used to compare whether the hash value of the main network and the hash value of the sentinel network are consistent;

[0085] The fourth acquisition unit is used to locate the difference transaction using the Merkle tree algorithm and obtain the longest chain of the main network if the hash value of the main network and the hash value of the sentinel network are inconsistent.

[0086] The correction unit is used to correct the local ledger based on the difference transaction and the longest chain.

[0087] This application provides a blockchain-based IoT patch security distribution method. It obtains basic and identity information of the device, then uses a vulnerability detection algorithm to check if the vulnerability information corresponding to the basic information exists in a known vulnerability database. If the vulnerability information exists, a virtual patch corresponding to the vulnerability information is retrieved from the vulnerability patch database. Next, the identity information is verified for validity based on the identity identifier. If the identity information is valid, the virtual patch is sent to the device for installation. Finally, after the virtual patch is installed, an attack is simulated on the device in an isolated environment, and the device is monitored to see if it successfully blocks the attack. If the device successfully blocks the attack, the virtual patch is sent to similar devices (devices of the same type as the current device). This method assigns a unique and tamper-proof identity to each device based on its identity identifier, effectively resisting attacks on device identities, solving the problem of difficult device identity authentication, and ensuring that only devices that pass identity verification can receive virtual patches. Attached Figure Description

[0088] To more clearly illustrate the technical solutions in the embodiments of this application 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 embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0089] Figure 1 A flowchart illustrating a blockchain-based IoT patch security distribution method provided in this application embodiment;

[0090] Figure 2 A flowchart illustrating an identity information verification method provided in an embodiment of this application;

[0091] Figure 3 A flowchart illustrating a method for storing results and records according to another embodiment of this application;

[0092] Figure 4This is a schematic diagram of the structure of a blockchain-based IoT patch security distribution system, which is provided as another embodiment of this application. Detailed Implementation

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

[0094] In this application, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0095] This application provides a blockchain-based IoT patch security distribution method, applied to a blockchain-based IoT patch security distribution system, to solve the problem of difficult device identity authentication.

[0096] Optionally, embodiments of this application provide a blockchain-based IoT patch security distribution system, including: a blockchain module, an IoT device terminal, an IoT cloud agent platform, a vulnerability patch database, a patch matching engine, an identity authentication module, a patch verification module, and a patch dissemination module.

[0097] Specifically, the blockchain module plays a central role in the distribution system, recording key information throughout the entire process of patch generation, verification, distribution, and deployment. Through blockchain's distributed ledger technology, each operational step is recorded as an immutable transaction record, stored and verified across multiple nodes in the blockchain network. This ensures the trustworthiness of the patch's origin, as all patch generation and release information is permanently recorded and cannot be maliciously modified. It also enables process traceability; in the event of security issues or the need for auditing, detailed information about every stage of the patch's creation and deployment can be retrieved through the blockchain.

[0098] The IoT device terminal acts as a proxy module for deploying virtual patches. This module is responsible for receiving virtual patch rules from other system components and executing these rules on the device terminal. It is a crucial link in the implementation of virtual patches on IoT devices, protecting against device vulnerabilities through interaction with the device's operating system and related applications. For example, when a device has a network protocol vulnerability, the virtual patch proxy module can intercept and modify relevant network packets, preventing malicious attacks from exploiting the vulnerability.

[0099] IoT cloud proxy platforms play a crucial role in the centralized management of IoT devices. They establish communication connections with IoT device terminals to collect detailed device information, including device model, manufacturer, hardware configuration, operating system, and firmware version. Based on this information, the IoT cloud proxy platform can accurately identify the device type and firmware version. It also detects known vulnerabilities in the devices.

[0100] The vulnerability patch database stores vulnerability information for various devices and their corresponding virtual patching rules. This information is the foundational data source for the system's vulnerability management and patch distribution. Vulnerability information includes detailed details such as the vulnerability's name, ID, description, scope of impact, and severity. Virtual patching rules define specific protection strategies and operational instructions for each vulnerability, such as modifying system configuration parameters or blocking specific types of network requests. The database is updated regularly to incorporate newly discovered vulnerabilities and their corresponding patching rules, ensuring the system can cope with constantly evolving security threats.

[0101] Patch matching engine: Based on the device vulnerability information detected by the IoT cloud agent platform, it automatically matches the vulnerability patch database to find the corresponding virtual patch.

[0102] The identity authentication module utilizes a blockchain-based Device Identity (DID) system to achieve device registration, authentication, and access control. A unique decentralized identity (DID) is generated for each IoT device, and this DID information is written to the blockchain module to ensure the immutability and uniqueness of the identity information. When a device sends an authentication request, the identity authentication module extracts the DID and Verifiable Credential (VC), calls the smart contract interface of the blockchain module, and verifies the validity of the DID and the signature of the VC. Based on the verification result, it grants or denies the device access to virtual patches and writes the authentication result (including device ID, authentication time, and access level) to the blockchain, forming an immutable authentication record. For example, only devices that have passed identity authentication and been granted the corresponding permissions can receive and install specific virtual patches, effectively preventing patches from being abused by malicious devices.

[0103] Patch verification module: Deployed on IoT device terminals, it is used to simulate attack behavior to verify the effectiveness of patches after they are deployed on the device.

[0104] Patch distribution module: After a patch is verified to be valid, it is used to distribute virtual patches to other similar devices.

[0105] Based on the aforementioned blockchain-based IoT patch security distribution system, this application provides a corresponding blockchain-based IoT patch security distribution method, such as... Figure 1 As shown, the specific steps include:

[0106] S101. Obtain the device's basic information and identity information.

[0107] Understandably, an IoT cloud agent platform needs to establish a communication connection with IoT device terminals in order to collect basic information about the devices. This basic information may include the device model, manufacturer, hardware configuration, operating system, firmware version, and so on.

[0108] The identity information needs to be sent to the identity authentication module for authentication, thereby ensuring the uniqueness of the device.

[0109] S102. Use vulnerability detection algorithms to check whether there is vulnerability information corresponding to the basic information in the known vulnerability database.

[0110] Understandably, in order to prevent malicious attacks from exploiting known vulnerabilities in the device, the IoT cloud proxy platform can first identify the device type and firmware version based on the device's basic information. Then, the built-in vulnerability detection algorithm of the IoT cloud proxy platform can be used to check whether there is vulnerability information corresponding to the basic information in the known vulnerability database. For example, by comparing the device's firmware version with the vulnerability information of the corresponding firmware version in the known vulnerability database, it can be determined whether the device faces a specific vulnerability risk. If there is vulnerability information corresponding to the basic information in the known vulnerability database, it means that the device has a known vulnerability. At this time, it needs to be dealt with in time to achieve vulnerability protection for the device. Therefore, step S103 is executed.

[0111] Alternatively, if the vulnerability information corresponding to the basic information does not exist in the known vulnerability database, it means that the device does not have any known vulnerabilities, and therefore there is no need to protect the device.

[0112] S103. Obtain the virtual patch corresponding to the vulnerability information from the vulnerability patch database.

[0113] Specifically, the vulnerability patch database stores vulnerability information for various devices and their corresponding virtual patch rules. Therefore, when the vulnerability database contains vulnerability information corresponding to the basic information, the Buffon matching engine will automatically use an efficient matching algorithm to match the detected vulnerability information in the vulnerability patch database to obtain virtual patches. This allows for the rapid and accurate selection of applicable virtual patches from the vast database. For example, based on key information such as the vulnerability number, device type, and firmware version, it performs precise queries and correlation matching in the database to determine the most suitable virtual patch rule for the device vulnerability.

[0114] S104. Verify the validity of the identity information based on the identity identifier in the identity information.

[0115] It should be noted that after the patch matching engine matches the corresponding virtual patch for the device, it needs to verify the device's identity information before sending the virtual patch to the device. Only when the device's identity information is verified can the device be granted permission to access the virtual patch, thereby preventing the patch from being abused by malicious devices. Therefore, in this embodiment, the identity information is verified based on the identity identifier in the identity information. If the identity information is valid, it means that the virtual patch can be sent to the device, so step S105 is executed.

[0116] Optionally, if the identity information is invalid, it indicates that the device may be malicious, and therefore sending virtual patches to the device is prohibited.

[0117] Optionally, in another embodiment of this application, one specific implementation of step S104 is as follows: Figure 2 As shown, the specific steps include:

[0118] S201. Extract the device's identity identifier, binding information, and signature of verifiable credentials from the identity information.

[0119] Understandably, identity identification is based on blockchain technology for device registration, authentication, and access management. This generates a unique decentralized identity (DID) for each IoT device. The DID information, or identity information, then needs to be written into the blockchain module to ensure its immutability and uniqueness. Therefore, before sending a virtual patch to the device, the device needs to send its identity information to the identity authentication module. The module then extracts the device's DID and the signature and binding information of the verifiable credential (VC). This binding information may include the device's hardware fingerprint (such as CPU serial number, MAC address hash), device public key, and other information.

[0120] S202. Check whether the identity identifier has been registered on the blockchain and whether it is in a valid state.

[0121] Understandably, after extracting the device's identity identifier, binding information, and the signature of the verifiable credential, the identity authentication module will call the smart contract interface of the blockchain module to query whether the identity identifier has been registered on the blockchain and whether it is in a valid state (not revoked or expired). If the identity identifier has been registered on the blockchain and is in a valid state, then step S203 will be executed.

[0122] Optionally, if the identity identifier is not registered on the blockchain and is not in a valid state, the device's identity information is determined to be invalid.

[0123] S203. Check whether the identity and binding information are consistent with the information of the device recorded in the blockchain.

[0124] Specifically, when the identity identifier is registered on the blockchain and is in a valid state, it is also necessary to verify whether the identity identifier and binding information are consistent with the information recorded in the blockchain. If they are consistent, then step S204 is executed.

[0125] Optionally, if they do not match, the device's identity information is deemed invalid.

[0126] S204. Extract the public key of the verifiable credential from the blockchain.

[0127] Understandably, when the identity and binding information match the information of the device recorded in the blockchain, the next step is to verify the verifiable credential. The verifiable credential is digitally signed by the root authentication node in the system using its private key. Therefore, the identity authentication module needs to obtain the public key of the verifiable credential from the blockchain in order to verify the verifiable credential subsequently.

[0128] S205. Verify the signature using the public key, and if the signature passes verification, confirm that the identity information is valid.

[0129] Specifically, after obtaining the public key of the verifiable credential, the signature of the verifiable credential is verified using the public key, that is, whether the public key and the signature are consistent. If they are consistent, the signature is verified and the device can be granted access to the virtual patch.

[0130] Optionally, if there is a discrepancy, the signature is determined to have failed verification, thus the device's identity information is deemed invalid, and the device is denied permission to access the virtual patch.

[0131] S105. Send the virtual patch to the device so that the device can install the virtual patch.

[0132] Understandably, when the identity information is valid, the system will send a virtual patch to the device so that the device can deploy the virtual patch to prevent malicious attacks.

[0133] S106. After the virtual patch is installed on the device, simulate the attack behavior on the device in an isolated environment and monitor whether the device successfully blocks the attack behavior.

[0134] It should be noted that, in order to verify the effectiveness of the virtual patch and whether it can really resist malicious attacks, in this embodiment of the application, after the virtual patch is deployed on the device, the patch verification module will receive and deploy the virtual patch issued by the virtual patch proxy module, and simulate the attack behavior on the known vulnerability of the device in the isolated environment, so as to observe whether the device reconstructs and blocks the attack. Therefore, if the device successfully blocks the attack behavior, it indicates that the virtual patch is effective, and thus step S107 is executed.

[0135] Optionally, if the device fails to block the attack, it indicates that the virtual patch is invalid. In this case, the patch rollback mechanism will be triggered to restore the device to its state before the patch was deployed and generate an alarm message to be reported to the IoT cloud agent platform so that further remedial measures can be taken in a timely manner.

[0136] S107. Send the virtual patch to similar devices.

[0137] In this context, "same type of equipment" refers to equipment that is of the same type as the equipment.

[0138] Understandably, when a device successfully blocks an attack, the patch distribution module will automatically distribute the virtual patch to other IoT devices of the same type, so that similar devices can also prevent malicious attacks.

[0139] Specifically, in the vulnerability patch database, each virtual patch is associated with metadata such as "applicable device type, firmware version, and hardware model" (this metadata is recorded and stored when the patch is generated). When the patch distribution module reads verified patch transaction records from the blockchain, it extracts the applicable metadata for the patch rule and then filters it based on the device DID registration information stored in the blockchain, including device type and firmware version, and the device information database synchronized with the IoT cloud agent platform. Then, based on the applicable device type and firmware version, it filters out a list of similar devices. Next, it calls the identity authentication module interface to confirm that similar devices in the list have receiving permissions. After confirming permissions, the patch is distributed in batches to similar devices through an encrypted channel.

[0140] Optionally, to ensure that the verification results of identity information are immutable and that the records of distributing virtual patches to similar devices are traceable, another embodiment of this application also provides a method for storing results and records, such as... Figure 3 As shown, the specific steps include:

[0141] S301. Obtain the verification results of identity information and the dissemination information of virtual patches.

[0142] In this context, "diffusion information" refers to information that sends virtual patches to similar devices.

[0143] Specifically, the verification results may include the device ID, authentication time, and permission level, etc.

[0144] The diffusion information may include a list of target devices, diffusion time, and result status.

[0145] S302. Store the verification results and dissemination information in the blockchain.

[0146] Optionally, to ensure the verification results are immutable, they can be written to the blockchain. Similarly, to create a diffusion record of the diffusion information, improve patch coverage, and ensure the diffusion process is auditable and traceable, the diffusion information of the virtual patch can be written to the blockchain, thus forming a diffusion record.

[0147] Optionally, the verification result of the validity of the virtual patch can be encrypted and uploaded to the extended field of the patch transaction contained in the blockchain.

[0148] Optionally, since the blockchain runs through the entire distribution process, and each operation generates a blockchain transaction, triggering transaction processing in the blockchain module, another embodiment of this application also provides a transaction processing method for the blockchain module, including specific processes A1 to A9:

[0149] A1: Obtain the data packet sent by the sender.

[0150] It should be noted that the core processing node of the blockchain module includes a processor and a transceiver. The transceiver uses a dual-mode communication module, supporting adaptive switching between TCP / IP and UDP protocols. When the first peer node of another node in the blockchain network that is communicating with the current core processing node and sending virtual patch transaction bytes to it receives the virtual patch transaction bytes (these virtual patch transaction bytes are generated when patch-related operations occur in the system, such as the "patch distribution" transaction generated when the IoT cloud agent platform prepares to distribute a patch, or the "patch verification result" transaction generated when the patch verification module uploads the patch verification result), it will first filter corrupted data packets through hardware-level CRC32 checksum. Therefore, it will filter from the received virtual patch transaction bytes. Thus, the sender will calculate the CRC32 value of the transaction byte and send it with the data packet so that the system can obtain the data packet sent by the sender. The data packet can include the virtual patch transaction byte and its corresponding checksum.

[0151] A2: Calculate the target check value of the virtual patch transaction bytes and determine whether the check value is consistent with the target check value.

[0152] Specifically, when the system receives a virtual patch transaction byte, it recalculates the CRC32 value of the received virtual patch transaction byte, which is the target checksum, and compares it with the checksum attached by the sender. If the checksum does not match the target checksum, process A3 is executed. If the checksum matches the target checksum, process A4 is executed.

[0153] A3: If the checksum does not match the target checksum, the data packet will be dropped.

[0154] Understandably, when the checksum does not match the target checksum, the system will determine that the data packet sent by the sender is not corrupted and will drop the data packet to avoid consuming memory space.

[0155] A4: If the checksum matches the target checksum, then parse the data packet to obtain the parsed data, and based on the parsed data, verify whether the virtual patch is complete and whether it matches the device.

[0156] Specifically, when the verification value matches the target verification value, the valid data is transmitted to the processor of the blockchain module. Since the data in the data packet has undergone pre-structured encapsulation, the data packet is first parsed to obtain the patch hash value generated using the SHA-256 algorithm, the three-level device type field covering the hardware model (e.g., RK3588, Intel i7-13700K), the operating system kernel version (e.g., Linux 5.15.0, Android 13), and the firmware version number. This facilitates the core processing node in quickly selecting suitable nodes, as well as the timestamp encrypted using elliptic curve cryptography (ECC secp256k1). After obtaining this parsed data, the system verifies whether the virtual patch is complete and matches the device, thus proceeding with the virtual patch propagation process. Therefore, if the virtual patch is complete and matches the device, process A5 is executed.

[0157] Optionally, if the virtual patch is incomplete or incompatible with the device, the virtual patch cannot be distributed, and the transaction will be terminated.

[0158] A5: If the virtual patch is complete and matches the device, then multiple delayed nodes are used to synchronize the virtual patch transaction bytes and the virtual patch transaction bytes are fragmented to obtain multiple fragment nodes.

[0159] The first shard node carries the shard number and the total number of shards.

[0160] Specifically, when the virtual patch is complete and matches the device, it means that the virtual patch can be propagated. Therefore, during the transaction propagation phase, the processor will start the distributed propagation engine and, based on the preset network topology, use the improved Gossip protocol: in the initial stage, the virtual patch transaction bytes are synchronized to 3-5 low-latency neighbor nodes (the latency threshold is set to 50ms), that is, multiple latency nodes. At the same time, the processor will fragment the transaction bytes to obtain multiple fragment nodes. The size of each fragment is controlled within 1MB. The fragment header carries the fragment sequence number and the total number of fragments, so as to use the fragment nodes for propagation.

[0161] A6: Send each shard node to the sender in sequence so that the sender can reassemble the data according to each shard node and record the acknowledgment signal of each shard node.

[0162] Understandably, after obtaining all shard nodes, nodes with a response rate exceeding 95% in the past 10 minutes are prioritized. The key calculation details are as follows: the edge weight wij is determined by RTT, jitter, and packet loss rate, where σij is the standard deviation of RTT and jitter, and pij is the packet loss rate (0–1).

[0163]

[0164] in, The round-trip time between node i and node j reflects network latency.

[0165] Execute constrained Dijkstra's algorithm:

[0166]

[0167] Where s represents the source node and v represents the delay node.

[0168] Neighbor weights are updated every 100ms:

[0169]

[0170] Among them, Sent i Ack represents the total number of transaction shards sent to neighbor node i. i This represents the number of ACK acknowledgments received by neighbor node i.

[0171] Sampling probability according to Normalization:

[0172]

[0173] Where, ω i The forwarding weight of neighbor node i combines response rate and latency, ω iThe larger the value, the higher the node's forwarding efficiency, and the higher its priority in being selected for the forwarding list.

[0174] If R i <0.95 or RTT i >50 ms, among the neighboring nodes of the blockchain core processing node currently participating in Gossip protocol forwarding, those satisfying "R i <0.95” or “RTT” i Nodes meeting the condition ">50ms" (where Ri is the node's acknowledgment rate, i.e., Ack count / transmission count, and RTTi is the node's round-trip time) are immediately downgraded to passive relays, stopping the next round of Gossip. Simultaneously, the processor sequentially sends each fragment node to the sender, enabling the sender to reassemble the data based on the fragment nodes. Each time the sender receives a fragment node, it records the acknowledgment signal for that node, so that each acknowledgment signal can be sent to the receiver.

[0175] A7: Obtain multiple acknowledgment signals and determine whether the sender has received all fragment nodes based on each acknowledgment signal.

[0176] Specifically, the receiver will receive an acknowledgment signal from each shard node received by the sender. In order to know whether the sender has received all shard nodes, it is also necessary to determine whether the sender has received all shard nodes based on each acknowledgment signal. If the sender has received all shard nodes, then process A8 is executed; if the sender has not received all shard nodes, then process A9 is executed.

[0177] A8: If the sender receives all shard nodes, it packages the virtual patch transaction bytes and stores the packaged virtual patch transaction bytes in the blockchain bytes.

[0178] Understandably, when the sender receives all the shard nodes, the processor will package the virtual patch transaction bytes and store the packaged virtual patch transaction bytes in the blockchain's blockchain bytes, so that they can wait for the next step of processing.

[0179] A9: If the sender does not receive all fragment nodes, a retransmission mechanism is triggered.

[0180] Specifically, when the sender does not receive all the fragment nodes, it will trigger the retransmission mechanism for the fragment nodes that failed to be sent. That is, the retransmission interval is increased according to the exponential backoff algorithm.

[0181] Optionally, after packaging the virtual patch object bytes into the blockchain bytes, the transceiver of the blockchain module will further diffuse the blockchain bytes. Therefore, in another embodiment of this application, a method for diffusering blockchain bytes is also provided, including specific processes B1 to B5:

[0182] B1: Obtain the blockchain bytes and parse them to obtain the target parsed data.

[0183] Specifically, when the transceiver receives blockchain bytes containing the virtual patch transaction bytes from the second peer node, these bytes are generated by functional modules within the system during corresponding operations. For example, when the IoT cloud proxy platform initiates a patch distribution operation, it generates a patch distribution transaction. These transactions are then propagated throughout the blockchain network and subsequently packaged into blocks to form blockchain bytes containing the transaction. The blockchain bytes are then parsed to obtain the target parsed data. This target parsed data may include a block header containing the previous block hash (32 bytes), Merkle root hash (32 bytes), timestamp (64 bits), difficulty value (32 bits), and random number (32 bits). The block body stores the serialized data of this transaction and 100-500 other transactions in a linked list format.

[0184] B2: Verify whether the hash value of the preceding block is consistent with the hash value of the current block in the local blockchain, and whether the virtual patch transaction byte is in the block body of the blockchain.

[0185] Understandably, after obtaining the target parsed data, the processor will initiate a parallel verification thread: on the one hand, verifying the consistency between the previous block hash and the latest block hash in the local ledger; on the other hand, verifying whether the virtual patch transaction byte actually exists in the block body through a Merkle tree path, with the verification time controlled within 200ms, thereby initiating the hierarchical diffusion strategy for blockchain byte propagation. Therefore, if the hash value of the previous block is consistent with the hash value of the current local block, and the virtual patch transaction byte is in the block body of the current block, the hierarchical diffusion strategy can be initiated, thus executing process B3.

[0186] Optionally, if the hash value of the preceding block is inconsistent with the hash value of the current block in the local area, and the virtual patch transaction byte is not in the block body of the blockchain, no operation is required or the blockchain byte is deleted from the blockchain.

[0187] B3: If the hash value of the preceding block is consistent with the hash value of the current block in the local blockchain, and the virtual patch transaction byte is in the block body of the current block, then multiple seed nodes in the blockchain are used to synchronize the data in the block body.

[0188] Seed nodes refer to nodes whose storage space in the blockchain is greater than a preset threshold and whose online time is greater than a preset time.

[0189] Specifically, when the hash value of the current block is consistent with the hash value of the local current block, and the virtual patch transaction byte is in the block body of the current block, the core processing node will first synchronize the complete block data to the three seed nodes in the network. The seed nodes need to have a storage space of more than 1TB and an online time of more than 90%. Then, the seed nodes will spread the data step by step in the hierarchy of "backbone node - edge node". Therefore, it is necessary to use multiple seed nodes in the blockchain to synchronize the data in the block body before the seed nodes can be used for hierarchical diffusion.

[0190] B4: After the synchronization process is completed, the synchronized data of each seed node is forwarded to the backbone node so that the backbone node can forward the synchronized data.

[0191] Among them, backbone nodes refer to nodes whose bandwidth is not less than the preset bandwidth threshold and which have passed node verification.

[0192] It should be noted that after the seed nodes have synchronized the data, the data is then distributed hierarchically from seed nodes to edge nodes. Therefore, it is necessary to select backbone nodes first. The identification of backbone nodes in the blockchain network is based on a "node attribute declaration + network verification" mechanism. Specifically, when a node joins the network, it will proactively declare its hardware resource attributes (such as bandwidth ≥ 1Gbps, storage space ≥ 500GB, online time commitment ≥ 80%, etc.) to the seed nodes or core nodes. The seed nodes will evaluate the nodes declared as "backbone node candidates" approximately every hour. Source verification (such as detecting actual bandwidth, counting online time, etc.) will mark the verified nodes as "backbone nodes". Their node ID, public key, resource attributes and other information will be written into the blockchain's "node attribute transaction" for the entire network to query and synchronize. If the backbone node subsequently fails to meet the standards such as bandwidth decline or insufficient online time, the seed node will initiate a "backbone node downgrade" transaction to remove it, so as to dynamically maintain the backbone node resources to meet the diffusion requirements. Therefore, after the backbone node is selected, the seed node will send its synchronized data to the backbone node so that the backbone node can forward and spread it.

[0193] B5: When the number of times the backbone node receives data reaches the preset number, stop the forwarding operation of the backbone node, and update the association mapping table according to the location information of the virtual patch transaction bytes and the block body.

[0194] It should be noted that in this embodiment, the seed node needs to forward three identical block data to the backbone node. The "three identical block data" is a result of the distributed propagation characteristics of the blockchain network. That is, after the blockchain consensus node generates a new block, it first synchronizes the block data to 3-5 neighboring nodes (including seed nodes, other consensus nodes, etc.) connected to itself. Then, the node that receives the initial block data (such as the seed node) forwards it to the backbone node according to the hierarchical diffusion strategy. Since the blockchain network is a distributed topology, the same block will propagate through different node paths. Finally, the backbone node receives multiple blocks with consistent content hashes from different upstream nodes (seed nodes, other core nodes, etc.) in a short period of time (such as within 100ms).

[0195] Therefore, when the backbone node receives data three times, it obtains three identical block data. At this point, it is determined that the block has achieved initial diffusion in the network, and the backbone node will stop forwarding to avoid wasting network bandwidth.

[0196] Finally, after the diffusion is complete, the processor needs to update the association mapping table, which is the built-in transaction-block association mapping table. Once the virtual patch transaction bytes and the corresponding block bytes have been verified, the local ledger index will be automatically updated to bind the patch transaction with the block location information (block height, offset of the transaction within the block) for easy subsequent querying and tracing.

[0197] Optionally, the blockchain module also involves the primary / backup switching of the sentinel network, specifically designed to combat discriminatory forwarding by centralized nodes. Therefore, in another embodiment of this application, a primary / backup switching method for the sentinel network is also provided, including specific processes C1 to C6:

[0198] C1: When a monitoring command for the main network status is received, determine whether the core node has triggered a primary / backup switch.

[0199] Among them, core nodes refer to the nodes in the main network of the blockchain that are responsible for transaction processing and block propagation.

[0200] Specifically, when a monitoring command for the mainnet status is received, the Sentinel Network core processing node will activate the King Status Detection Engine to determine whether the core node has triggered a master-slave switch. The processor has a built-in "mainnet status monitoring engine" that compares the transaction forwarding efficiency of the core nodes in the blockchain mainnet that are responsible for transaction processing and block propagation with that of the Sentinel nodes in real time: the mainnet transaction response time (the interval from sending to receiving ACK) is sampled every 500ms. When the sampled value exceeds twice the average response time of the Sentinel Network for three consecutive times, or when the success rate of the mainnet node in forwarding transactions for a specific device type field is detected to be less than 60%, the "master-slave switch" is automatically triggered. Therefore, process C2 needs to be executed next.

[0201] Optionally, if the core node does not trigger a primary / standby switchover, monitoring will continue.

[0202] In addition, the Sentinel Network in the blockchain module serves as a decentralized backup channel. Its core processing nodes include independent processors and enhanced transceivers, specifically designed to combat discriminatory forwarding by centralized nodes. The specific mechanism is as follows: The transceiver adopts a "master-slave dual-band communication module," supporting the overlay of a decentralized discovery protocol on top of the original TCP / UDP protocol. New nodes must pass "Sentinel qualification verification"—submitting their public key, network behavior logs for the past 72 hours, and hardware resource proof to three certified Sentinel nodes. If at least two of the three certified Sentinel nodes pass the verification, a "Sentinel Node Authentication Certificate" (containing the signatures of the three nodes) is generated and sent back to the new node. If the verification fails, the new node is informed of the reason for the failure (e.g., insufficient resources, abnormal logs). After successful verification, the node is added to the Sentinel node list, which is updated every 10 minutes via a distributed hash table. The information of certified sentinel nodes in the sentinel network within the blockchain module can be obtained through a triple mechanism: real-time query from a distributed hash table, on-chain traceability of the blockchain, and local cache synchronization. The DHT maintains a "list of certified sentinel nodes" containing node public key hashes, communication addresses, and qualification validity periods, which is automatically updated every 10 minutes. Nodes can query real-time information using "sentinel_node_list" as the key. The blockchain stores "sentinel node certification transactions" (containing node public keys, hardware resource proof digests, and signatures from three certified nodes) for traceability to prevent DHT tampering. The blockchain core processing node synchronizes this list from the DHT every 5 minutes and caches it locally, allowing new nodes to select nodes with good online status when initiating sentinel qualification verification, thus improving interaction efficiency. The transceiver listens on a dedicated port by default to avoid port blocking. The processor uses double-layer encryption for transmitted virtual patch transactions and blockchain bytes: the outer layer uses the ChaCha20-Poly1305 algorithm to encrypt the transmission frame, while the inner layer retains the original blockchain's ECC encryption layer. Simultaneously, all traceable source node metadata (such as MAC address and IP geotag) is stripped from the data packets, retaining only the node's public key hash. The transceiver employs a "random delay forwarding strategy" during forwarding, adding a random delay of 10-50ms to each data packet to avoid traffic feature analysis.

[0203] C2: If the core node triggers a primary / standby switch, stop sending data to the core node and instead send the data to high-reputation nodes in the sentinel node list for propagation.

[0204] Among them, high-reputation nodes refer to nodes whose forwarding success rate is greater than a preset threshold within a preset time period and whose offline time is not greater than a preset duration.

[0205] Specifically, when a core node triggers a primary / backup switch, the transceiver immediately stops sending data to the core node of the main network after the switch. Instead, it propagates data through "high-reputation nodes" (with a forwarding success rate of ≥98% in the past 24 hours and an offline duration of ≤5 minutes) in the sentinel node list. The initial number of synchronization nodes is set to 5-8 (higher than the main network to improve the ability to resist node failure).

[0206] C3: After propagation is complete, connect the core node to the main network and the sentinel network respectively, and obtain the hash value of the main network and the hash value of the sentinel network.

[0207] Specifically, after the propagation is complete, the sentinel network and the main network will adopt a "dual-write verification mechanism": when a core node with dual network access capability, capable of establishing communication connections with both the main network node and the sentinel network node at the same time, and responsible for data synchronization and verification, accesses both the main network and the sentinel network, the processor will subsequently perform hash comparison on the blockchain bytes received by the two networks. Therefore, it is necessary to first obtain the hash value of the main network and the hash value of the sentinel network.

[0208] C4: Compare whether the hash values ​​of the main network and the sentinel network are consistent.

[0209] Understandably, after obtaining the hash values ​​of the main network and the sentinel network, the processor will perform a hash comparison on the blockchain bytes received by the two networks. If the hash values ​​of the main network and the sentinel network are inconsistent (allowing temporary forks within 2 blocks), the fork repair process will be initiated, i.e., process C5 will be executed.

[0210] Optionally, if the hash value of the main network is consistent with the hash value of the sentinel network, then it is determined that the data in the main network and the sentinel network are consistent, and the local ledger can be updated normally.

[0211] C5: If the hash value of the main network and the hash value of the sentinel network are inconsistent, the Merkle tree algorithm is used to locate the difference transaction and obtain the longest chain of the main network.

[0212] It's important to note that when the hash value of the main network and the hash value of the Sentinel network are inconsistent, a Merkle tree is used to compare the differing transactions layer by layer. The local ledger is corrected based on the longest chain on the main network, but a backup of the Sentinel network forked blocks is retained (stored for 7 days) for tracking main network anomalies. Therefore, when the hashes of the Sentinel network block and the main network block are inconsistent, the Merkle roots of the main network block and the Sentinel network block are extracted first. Then, the Merkle roots of the main network block and the Sentinel network block are compared to see if they are consistent. If they are inconsistent, the Merkle tree hierarchy corresponding to the two blocks is obtained. The hash values ​​are compared starting from the next level of child nodes of the root node. Branches with no differences are excluded, and the subtree with differences is focused on and compared recursively layer by layer until the leaf node level of the Merkle tree (each node in this layer corresponds to the SHA-256 hash of a transaction). This is used to locate the specific differing transaction. Then, the lengths of the main network chain to which Block_M belongs and the Sentinel network chain to which Block_S belongs are compared to obtain the longest chain on the main network.

[0213] C6: Correct the local ledger based on the difference in transactions and the longest chain.

[0214] Understandably, after obtaining the divergent transactions and the longest chain, the divergent transactions and the longest chain are used as quasi-corrected local ledgers (deleting local transactions that are consistent with "non-longest chain" and replacing them with transactions from the longest chain), while retaining backups of Sentinel fork blocks for tracing mainnet anomalies.

[0215] This application provides a blockchain-based IoT patch security distribution method. It obtains basic and identity information of the device, then uses a vulnerability detection algorithm to check if the vulnerability information corresponding to the basic information exists in a known vulnerability database. If the vulnerability information exists, a virtual patch corresponding to the vulnerability information is retrieved from the vulnerability patch database. Next, the identity information is verified for validity based on the identity identifier. If the identity information is valid, the virtual patch is sent to the device for installation. Finally, after the virtual patch is installed, an attack is simulated on the device in an isolated environment, and the device is monitored to see if it successfully blocks the attack. If the device successfully blocks the attack, the virtual patch is sent to similar devices (devices of the same type as the current device). This method assigns a unique and tamper-proof identity to each device based on its identity identifier, effectively resisting attacks on device identities, solving the problem of difficult device identity authentication, and ensuring that only devices that pass identity verification can receive virtual patches.

[0216] Another embodiment of this application provides a blockchain-based IoT patch security distribution system, such as... Figure 4 As shown, it specifically includes the following units:

[0217] The information acquisition unit 401 is used to acquire the device's basic information and identity information.

[0218] The vulnerability detection unit 402 is used to detect whether there is vulnerability information corresponding to the basic information in the known vulnerability database using vulnerability detection algorithms.

[0219] The patch acquisition unit 403 is used to acquire the virtual patch corresponding to the vulnerability information from the vulnerability patch database if the vulnerability information corresponding to the basic information exists in the known vulnerability database.

[0220] The identity verification unit 404 is used to verify whether the identity information is valid based on the identity identifier in the identity information.

[0221] The patch sending unit 405 is used to send a virtual patch to the device if the identity information is valid, so that the device can install the virtual patch.

[0222] The monitoring unit 406 is used to simulate attack behavior on the device in an isolated environment after the virtual patch is installed on the device, and to monitor whether the device successfully blocks the attack behavior.

[0223] The patch distribution unit 407 is used to send a virtual patch to similar devices if the device successfully blocks the attack. "Similar devices" refers to devices of the same type as the device being attacked.

[0224] It should be noted that the specific working process of the above modules in the embodiments of this application can be referred to steps S101 to S107 in the above method embodiments, and will not be repeated here.

[0225] Optionally, in another embodiment of this application, an authentication unit 404 in a blockchain-based IoT patch security distribution system includes:

[0226] The extraction unit is used to extract the device's identity identifier, binding information, and signature of verifiable credentials from the identity information.

[0227] The identification detection unit is used to detect whether the identity identifier has been registered on the blockchain and whether it is in a valid state.

[0228] The information detection unit is used to detect whether the identity and binding information are consistent with the information of the device recorded in the blockchain if the identity is registered on the blockchain and is in a valid state.

[0229] The public key extraction unit is used to extract the public key of the verifiable credential from the blockchain if the identity and binding information match the information of the device recorded in the blockchain.

[0230] The signature verification unit is used to verify the signature using a public key, and when the signature passes verification, it determines that the identity information is valid.

[0231] Optionally, another embodiment of this application provides a blockchain-based IoT patch security distribution system, which further includes:

[0232] The first acquisition unit is used to acquire the verification result of the identity information and the dissemination information of the virtual patch. The dissemination information refers to the information on sending the virtual patch to similar devices.

[0233] Storage units are used to store verification results and dissemination information into the blockchain.

[0234] Optionally, another embodiment of this application provides a blockchain-based IoT patch security distribution system, which further includes:

[0235] The second acquisition unit is used to acquire the data packet sent by the sender. The data packet includes at least the virtual patch transaction bytes and their corresponding checksum.

[0236] The calculation unit is used to calculate the target verification value of the virtual patch transaction byte and determine whether the verification value is consistent with the target verification value.

[0237] The packet loss unit is used to process data packets by dropping them if the checksum does not match the target checksum.

[0238] The verification unit is used to parse the data packet if the verification value matches the target verification value, obtain the parsed data, and verify whether the virtual patch is complete and whether it matches the device based on the parsed data.

[0239] The first synchronization unit is used to synchronize the virtual patch transaction bytes using multiple delay nodes if the virtual patch is complete and matches the device, and to fragment the virtual patch transaction bytes to obtain multiple fragment nodes. The first fragment node carries the fragment sequence number and the total number of fragments.

[0240] The reassembly unit is used to send each fragment node to the sender in sequence, so that the sender can reassemble the fragments according to each fragment node and record the acknowledgment signal of each fragment node.

[0241] The node determination unit is used to acquire multiple acknowledgment signals and determine whether the sender has received all fragment nodes based on each acknowledgment signal.

[0242] The packaging unit is used to package the virtual patch transaction bytes if the sender receives all shard nodes, and then store the packaged virtual patch transaction bytes in the blockchain bytes.

[0243] The triggering unit is used to trigger the retransmission mechanism if the sender has not received all the fragment nodes.

[0244] Optionally, another embodiment of this application provides a blockchain-based IoT patch security distribution system, which further includes:

[0245] The third acquisition unit is used to acquire blockchain bytes and parse them to obtain target parsed data. The target parsed data includes at least the hash value of the preceding block of the blockchain bytes.

[0246] The verification unit is used to verify whether the hash value of the preceding block is consistent with the hash value of the current block in the local area, and whether the virtual patch transaction byte is in the block body of the blockchain.

[0247] The second synchronization unit is used to synchronize the data in the block body using multiple seed nodes in the blockchain if the hash value of the preceding block is consistent with the hash value of the current local block, and the virtual patch transaction byte is in the block body of the current block. Seed nodes refer to nodes in the blockchain whose storage space is greater than a preset threshold and whose online time is greater than a preset duration.

[0248] The forwarding unit, after synchronization processing is complete, forwards the synchronized data from each seed node to the backbone node, enabling the backbone node to forward the synchronized data. The backbone node refers to a node with a bandwidth not less than a preset bandwidth threshold and that has passed node verification.

[0249] The update unit is used to stop the forwarding operation of the backbone node when the number of times the backbone node receives data reaches a preset number, and to update the association mapping table according to the location information of the virtual patch transaction bytes and the block body.

[0250] Optionally, another embodiment of this application provides a blockchain-based IoT patch security distribution system, which further includes:

[0251] The judgment unit is used to determine whether the core node has triggered a master-slave switch when it receives a monitoring instruction on the main network status. The core node refers to the node in the blockchain's main network that is responsible for transaction processing and block propagation.

[0252] The stop unit is used to stop sending data to the core node and instead send the data to high-reputation nodes in the sentinel node list for propagation if the core node triggers a primary / standby switch. High-reputation nodes are defined as nodes whose forwarding success rate is greater than a preset threshold within a preset time period and whose offline time is no greater than a preset duration.

[0253] The connection unit is used to connect the core node to the main network and the sentinel network respectively after the propagation is complete, and to obtain the hash value of the main network and the hash value of the sentinel network.

[0254] The comparison unit is used to compare whether the hash value of the main network and the hash value of the sentinel network are consistent.

[0255] The fourth acquisition unit is used to locate the difference transaction using the Merkle tree algorithm and obtain the longest chain of the main network if the hash value of the main network is inconsistent with the hash value of the sentinel network.

[0256] The correction unit is used to correct the local ledger based on the difference in transactions and the longest chain.

[0257] It should be noted that the specific working process of each unit provided in the above embodiments of this application can be referred to the corresponding steps in the above method embodiments, and will not be repeated here.

[0258] It should also be noted that the blockchain-based IoT patch security distribution system provided in this application has the technical effects of any of the above embodiments, and will not be described in detail here.

[0259] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0260] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A blockchain-based IoT patch security distribution method, characterized in that, include: Obtain basic device information and identity information; The vulnerability detection algorithm is used to check whether the vulnerability information corresponding to the basic information exists in the known vulnerability database. If the known vulnerability database contains vulnerability information corresponding to the basic information, then the virtual patch corresponding to the vulnerability information is obtained from the vulnerability patch database; Verify the validity of the identity information based on the identity identifier in the identity information; If the identity information is valid, the virtual patch is sent to the device so that the device can install the virtual patch; After the virtual patch is installed on the device, an attack is simulated on the device in an isolated environment, and the device is monitored to see if it successfully blocks the attack. If the device successfully blocks the attack, the virtual patch is sent to a similar device; wherein, the similar device refers to a device of the same type as the device. Obtain the verification result of the identity information and the diffusion information of the virtual patch; wherein, the diffusion information refers to the information of sending the virtual patch to the similar devices; The verification results and the dissemination information are stored in the blockchain; The step of verifying the validity of the identity information based on the identity identifier in the identity information includes: Extract the device's identity identifier, binding information, and signature of verifiable credentials from the identity information; Check whether the identity identifier has been registered on the blockchain and whether it is in a valid state; If the identity identifier is registered on the blockchain and is in a valid state, then it is checked whether the identity identifier and the binding information are consistent with the information of the device recorded in the blockchain; If the identity identifier and the binding information are consistent with the information of the device recorded in the blockchain, then the public key of the verifiable credential is extracted from the blockchain; The signature is verified using the public key, and the identity information is determined to be valid when the signature passes verification.

2. The method according to claim 1, characterized in that, Also includes: Obtain the data packet sent by the sender; wherein the data packet includes at least virtual patch transaction bytes and its corresponding checksum; Calculate the target verification value of the virtual patch transaction bytes, and determine whether the verification value is consistent with the target verification value; If the verification value is inconsistent with the target verification value, the data packet will be dropped. If the verification value matches the target verification value, the data packet is parsed to obtain parsed data, and based on the parsed data, the completeness of the virtual patch and its compatibility with the device are verified. If the virtual patch is complete and matches the device, then multiple delay nodes are used to synchronize the virtual patch transaction bytes, and the virtual patch transaction bytes are fragmented to obtain multiple fragment nodes; wherein, the first fragment node carries the fragment sequence number and the total number of fragments; Each of the fragment nodes is sent to the sender in sequence, so that the sender can reassemble the data according to each fragment node and record the acknowledgment signal of each fragment node; Acquire multiple confirmation signals, and determine whether the sender has received all the shard nodes based on each confirmation signal; If the sender receives all the shard nodes, it packages the virtual patch transaction bytes and stores the packaged virtual patch transaction bytes in the blockchain bytes; If the sender does not receive all the fragment nodes, a retransmission mechanism is triggered.

3. The method according to claim 2, characterized in that, Also includes: The blockchain bytes are obtained and parsed to obtain target parsed data; wherein the target parsed data includes at least the hash value of the preceding block of the blockchain bytes; Verify whether the hash value of the preceding block is consistent with the hash value of the current block in the local area, and whether the virtual patch transaction byte is in the block body of the blockchain; If the hash value of the preceding block is consistent with the hash value of the current block in the local blockchain, and the virtual patch transaction byte is in the block body of the current block, then multiple seed nodes in the blockchain are used to synchronize the data in the block body; wherein, the seed node refers to a node in the blockchain whose storage space is greater than a preset threshold and whose online time is greater than a preset time. After the synchronization process is completed, the synchronized data of each seed node is forwarded to the backbone node so that the backbone node forwards the synchronized data; wherein, the backbone node refers to a node with a bandwidth not less than a preset bandwidth threshold and that has passed node verification. When the number of times the backbone node receives data reaches a preset number, the forwarding operation of the backbone node is stopped, and the association mapping table is updated according to the location information of the virtual patch transaction bytes and the block body.

4. The method according to any one of claims 1 to 3, characterized in that, Also includes: When a monitoring instruction for the mainnet status is received, it is determined whether the core node has triggered a primary / backup switch; wherein, the core node refers to the node in the main network of the blockchain that is responsible for transaction processing and block propagation; If the core node triggers a primary / backup switch, the data will stop being sent to the core node and will instead be sent to high-reputation nodes in the sentinel node list for propagation; wherein, the high-reputation node refers to a node whose forwarding success rate is greater than a preset threshold within a preset time period and whose offline time is not greater than a preset time. After the propagation is complete, the core node is connected to the main network and the sentinel network respectively, and the hash value of the main network and the hash value of the sentinel network are obtained. Compare whether the hash values ​​of the main network and the sentinel network are consistent; If the hash value of the main network and the hash value of the sentinel network are inconsistent, the Merkle tree algorithm is used to locate the difference transaction and obtain the longest chain of the main network. The local ledger is corrected based on the discrepancies in the transactions and the longest chain.

5. A blockchain-based IoT patch security distribution system, characterized in that, include: The information acquisition unit is used to acquire basic information and identity information of the device. The vulnerability detection unit is used to detect whether the vulnerability information corresponding to the basic information exists in the known vulnerability database using vulnerability detection algorithms; The patch acquisition unit is used to acquire a virtual patch corresponding to the vulnerability information from the vulnerability patch database if the vulnerability information corresponding to the basic information exists in the known vulnerability database. An identity verification unit is used to verify whether the identity information is valid based on the identity identifier in the identity information; A patch sending unit is configured to send the virtual patch to the device if the identity information is valid, so that the device can install the virtual patch; The monitoring unit is used to simulate attack behavior on the device in an isolated environment after the virtual patch is installed on the device, and to monitor whether the device successfully blocks the attack behavior. A patch distribution unit is configured to send the virtual patch to similar devices if the device successfully blocks the attack; wherein, the similar devices refer to devices of the same type as the device. Also includes: The first acquisition unit is used to acquire the verification result of the identity information and the diffusion information of the virtual patch; wherein, the diffusion information refers to the information of sending the virtual patch to the similar devices; A storage unit is used to store the verification results and the dissemination information into the blockchain; The authentication unit includes: The extraction unit is used to extract the device's identity identifier, binding information, and signature of verifiable credentials from the identity information; The identifier detection unit is used to detect whether the identity identifier has been registered on the blockchain and whether it is in a valid state; An information detection unit is used to detect whether the identity identifier and the binding information are consistent with the information of the device recorded in the blockchain if the identity identifier has been registered on the blockchain and is in a valid state. A public key extraction unit is used to extract the public key of the verifiable credential from the blockchain if the identity identifier and the binding information are consistent with the information of the device recorded in the blockchain. A signature verification unit is used to verify the signature using the public key, and when the signature passes verification, it determines that the identity information is valid.

6. The system according to claim 5, characterized in that, Also includes: The second acquisition unit is used to acquire data packets sent by the sender; wherein the data packets include at least virtual patch transaction bytes and their corresponding checksums; The calculation unit is used to calculate the target verification value of the virtual patch transaction byte and determine whether the verification value is consistent with the target verification value. The packet loss unit is used to drop the data packet if the check value is inconsistent with the target check value. The verification unit is used to parse the data packet to obtain parsed data if the verification value is consistent with the target verification value, and to verify whether the virtual patch is complete and whether it matches the device based on the parsed data. The first synchronization unit is configured to, if the virtual patch is complete and matches the device, use multiple delay nodes to synchronize the virtual patch transaction bytes and perform fragmentation processing on the virtual patch transaction bytes to obtain multiple fragmentation nodes; wherein, the first fragmentation node carries a fragmentation sequence number and a total number of fragments; The reassembly unit is used to sequentially send each of the fragment nodes to the sender, so that the sender can reassemble the fragments according to each of the fragment nodes and record the acknowledgment signals of each of the fragment nodes. A node determination unit is used to acquire multiple confirmation signals and determine, based on each confirmation signal, whether the sender has received all the fragment nodes. The packaging unit is used to package the virtual patch transaction bytes if the sender receives all the shard nodes, and store the packaged virtual patch transaction bytes in the blockchain bytes; The triggering unit is used to trigger a retransmission mechanism if the sender has not received all the fragment nodes.

Images