Internet of Things patch secure distribution method and system based on block chain

Abstract

The invention discloses an Internet of Things patch secure distribution method and system based on a block chain. The method comprises the steps of obtaining basic information and identity information of equipment; detecting whether vulnerability information corresponding to the basic information exists in a known vulnerability database or not by utilizing a vulnerability detection algorithm; if yes, acquiring a virtual patch corresponding to the vulnerability information from a vulnerability patch database; verifying whether the identity information is valid or not according to an identity label in the identity information; if yes, sending the virtual patch to the equipment, so that the equipment installs the virtual patch; after the virtual patch is installed on the equipment, simulating an attack behavior of the equipment in the isolation environment, and monitoring whether the equipment successfully blocks the attack behavior or not; and if the equipment successfully blocks the attack behavior, sending the virtual patch to the similar equipment. Therefore, each device is endowed with a unique and non-tampering identity according to the identity label, the attack on the device identity is effectively resisted, and the problem that the device identity is difficult to authenticate is effectively solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of Internet of Things security, and in particular to a patch security distribution method and system for Internet of Things based on a blockchain. BACKGROUND

[0002] With the wide application of Internet of Things (IoT) devices, the security of devices has become increasingly important. Due to the limitations of hardware resources, the complexity of communication protocols, and the differences in deployment environments, IoT devices often have many security vulnerabilities. These vulnerabilities can be exploited by attackers, resulting in loss of control of devices, data leakage, and even large-scale attacks on the entire network.

[0003] In order to deal with this situation, a virtual patch technology is used to solve the problem. Specifically, the virtual patch technology can effectively block the exploitation path of vulnerabilities by implementing protection rules outside the device rather than directly modifying the firmware of the device. This approach does not rely on firmware updates released by manufacturers, so it can quickly respond to security threats and reduce the time window for vulnerability exploitation. Virtual patches are usually implemented through network-level protection measures such as firewalls, IDS / IPS (intrusion detection / prevention systems), etc., to intercept possible attack traffic in a timely manner and protect the security of IoT devices.

[0004] Although the virtual patch technology has great potential in Internet of Things security, there are still some key problems with the current virtual patch mechanism. Due to the large number of IoT devices and the complexity of types, traditional identity authentication methods are difficult to adapt to large-scale deployment of IoT devices. Therefore, the identity authentication process of many devices has vulnerabilities, which can cause malicious devices to pretend to be legitimate devices to receive virtual patches. And this weak device identity authentication can further lead to patch misdelivery or incorrect deployment of protection rules, affecting the overall security. SUMMARY

[0005] Based on the above deficiencies of the prior art, the present application provides a patch security distribution method and system for Internet of Things based on a blockchain to solve the problem of difficult device identity authentication.

[0006] In order to achieve the above purpose, the present application provides the following technical solutions:

[0007] The first aspect of the present application provides a patch distribution security method for Internet of Things based on a blockchain, comprising:

[0008] obtaining basic information and identity information of a device;

[0009] detecting whether there is vulnerability information corresponding to the basic information in a known vulnerability database using a vulnerability detection algorithm;

[0010] if the base information corresponds to vulnerability information in the known vulnerability database, obtaining a virtual patch corresponding to the vulnerability information from a vulnerability patch database;

[0011] verifying whether the identity information is valid according to an identity identifier in the identity information;

[0012] if the identity information is valid, sending the virtual patch to the device to enable the device to install the virtual patch;

[0013] after the device completes installation of the virtual patch, simulating an attack behavior on the device in an isolated environment and monitoring whether the device successfully blocks the attack behavior;

[0014] if the device successfully blocks the attack behavior, sending the virtual patch to a same-type device; wherein the same-type device refers to a device of the same type as the device.

[0015] Optionally, in the blockchain-based IoT patch security distribution method described above, verifying whether the identity information is valid according to an identity identifier in the identity information comprises:

[0016] extracting an identity identifier, binding information, and a signature of a verifiable credential of the device from the identity information;

[0017] detecting whether the identity identifier is registered on a blockchain and is in a valid state;

[0018] if the identity identifier is registered on the blockchain and is in the valid state, detecting whether the identity identifier and the binding information are consistent with 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, extracting a public key of the verifiable credential from the blockchain;

[0020] verifying the signature using the public key, and determining that the identity information is valid when the signature passes verification.

[0021] Optionally, in the blockchain-based IoT patch security distribution method described above, the method further comprises:

[0022] obtaining a verification result of the identity information and diffusion information of the virtual patch; wherein the diffusion information refers to information of sending the virtual patch to the same-type device;

[0023] storing the verification result and the diffusion information in the blockchain.

[0024] Optionally, in the blockchain-based IoT patch security distribution method described above, further comprising:

[0025] acquiring a data packet sent by a sender; wherein the data packet at least includes a virtual patch transaction byte and a corresponding check value thereof;

[0026] calculating a target check value of the virtual patch transaction byte, and determining whether the check value is consistent with the target check value;

[0027] if the check value is not consistent with the target check value, performing packet loss processing on the data packet;

[0028] if the check value is consistent with the target check value, parsing the data packet to obtain parsed data, and verifying whether the virtual patch is complete and matches the device based on the parsed data;

[0029] if the virtual patch is complete and matches the device, synchronizing the virtual patch transaction byte using multiple delay nodes, and performing fragmentation processing on the virtual patch transaction byte to obtain multiple fragment nodes; wherein a first fragment node carries a fragment serial number and a total number of fragments;

[0030] sending each fragment node to the sender in turn, so that the sender reassembles according to each fragment node and records an acknowledgement signal of each fragment node;

[0031] acquiring multiple acknowledgement signals, and determining whether the sender has received all the fragment nodes according to each acknowledgement signal;

[0032] if the sender has received all the fragment nodes, packaging the virtual patch transaction byte, and storing the packaged virtual patch transaction byte into a blockchain byte;

[0033] if the sender has not received all the fragment nodes, triggering a retransmission mechanism.

[0034] Optionally, in the blockchain-based IoT patch security distribution method described above, further comprising:

[0035] acquiring the blockchain byte and performing parsing processing on the blockchain byte to obtain target parsed data; wherein the target parsed data at least includes a hash value of a previous block of the blockchain byte;

[0036] checking whether the hash value of the previous block is consistent with a hash value of a current block locally, and whether the virtual patch transaction byte is in a block body of the blockchain;

[0037] If the hash value of the previous block is consistent with the hash value of the current block locally, and the virtual patch transaction byte is in the block body of the current block, then the data in the block body is synchronized by using a plurality of seed nodes in the blockchain; wherein the seed node refers to a node in the blockchain whose storage space is greater than a preset threshold and whose online duration is greater than a preset duration;

[0038] After the synchronization processing is completed, the synchronized data of each seed node is forwarded to a backbone node, so that the backbone node forwards the synchronized data; wherein the backbone node refers to a node whose bandwidth is not less than a preset bandwidth threshold and which passes the node check;

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

[0040] Optionally, in the above-mentioned blockchain-based Internet of Things patch security distribution method, further comprising:

[0041] When the monitoring instruction of the main network state is received, it is judged whether the core node triggers the master-slave switching; wherein the core node refers to a node in the main network of the blockchain that undertakes transaction processing and block propagation;

[0042] If the core node triggers the master-slave switching, the data is stopped from being sent to the core node, and the data is sent to a high-reputation node 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 and whose offline duration is not greater than a preset duration in a preset time period;

[0043] After the propagation is completed, the core node is connected with 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] It is compared 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 not consistent, the difference transaction is located by using the Merkle tree algorithm, and the longest chain of the main network is obtained;

[0046] The local ledger is corrected according to the difference transaction and the longest chain.

[0047] The second aspect of the present application provides a blockchain-based Internet of Things patch security distribution system, comprising:

[0048] An information acquisition unit is configured to acquire basic information and identity information of a device;

[0049] a vulnerability detection unit configured to detect, by using a vulnerability detection algorithm, whether there is vulnerability information corresponding to the basic information in a known vulnerability database;

[0050] a patch acquisition unit configured to acquire, if there is the vulnerability information corresponding to the basic information in the known vulnerability database, a virtual patch corresponding to the vulnerability information from a vulnerability patch database;

[0051] an identity verification unit configured to verify, according to an identity in the identity information, whether the identity information is valid;

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

[0053] a monitoring unit configured to, after the device installs the virtual patch is completed, simulate an attack behavior on the device in an isolated environment, and monitor whether the device successfully blocks the attack behavior;

[0054] a patch distribution unit configured to, if the device successfully blocks the attack behavior, send the virtual patch to a same-type device; wherein the same-type device refers to a device of the same type as the device.

[0055] Optionally, in the blockchain-based IoT patch security distribution system, the identity verification unit comprises:

[0056] an extraction unit configured to extract an identity of the device, binding information, and a signature of a verifiable credential from the identity information;

[0057] an identity detection unit configured to detect whether the identity is registered on a blockchain and is in a valid state;

[0058] an information detection unit configured to, if the identity is registered on the blockchain and is in the valid state, detect whether the identity and the binding information are consistent with information of the device recorded in the blockchain;

[0059] a public key extraction unit configured to, if the identity and the binding information are consistent with the information of the device recorded in the blockchain, extract a public key of the verifiable credential from the blockchain;

[0060] a signature verification unit configured to verify the signature by using the public key, and determine that the identity information is valid when the signature passes the verification.

[0061] Optionally, in the blockchain-based IoT patch security distribution system, the system further comprises:

[0062] a first obtaining unit, configured to obtain a verification result of the identity information and diffusion information of the virtual patch; wherein the diffusion information refers to information for sending the virtual patch to the same type of device;

[0063] a storage unit, configured to store the verification result and the diffusion information into a block chain.

[0064] Optionally, in the blockchain-based IoT patch security distribution system described above, further comprising:

[0065] a second obtaining unit, configured to obtain a data packet sent by a sender; wherein the data packet at least includes a virtual patch transaction byte and a corresponding check value thereof;

[0066] a calculation unit, configured to calculate a target check value of the virtual patch transaction byte, and determine whether the check value is consistent with the target check value;

[0067] a packet loss unit, configured to, if the check value is not consistent with the target check value, perform packet loss processing on the data packet;

[0068] a verification unit, configured to, if the check value is consistent with the target check value, analyze the data packet to obtain analysis data, and verify whether the virtual patch is complete and matches the device based on the analysis data;

[0069] a first synchronization unit, configured to, if the virtual patch is complete and matches the device, synchronize the virtual patch transaction byte by using a plurality of delay nodes, and perform fragmentation processing on the virtual patch transaction byte to obtain a plurality of fragment nodes; wherein a first fragment node carries a fragment serial number and a total number of fragments;

[0070] a recombination unit, configured to sequentially send each of the fragment nodes to the sender, so that the sender recombines according to each of the fragment nodes, and records an acknowledgement signal of each of the fragment nodes;

[0071] a node determination unit, configured to obtain a plurality of the acknowledgement signals, and determine whether the sender receives all the fragment nodes according to each of the acknowledgement signals;

[0072] a packaging unit, configured to, if the sender receives all the fragment nodes, package the virtual patch transaction byte, and store the packaged virtual patch transaction byte into a block chain byte;

[0073] a triggering unit, configured to, if the sender does not receive all the fragment nodes, trigger a retransmission mechanism.

[0074] Optionally, in the blockchain-based Internet of Things patch security distribution system, further comprising:

[0075] A third acquisition unit is configured to acquire the blockchain bytes and perform parsing processing on the blockchain bytes to obtain target parsing data, wherein the target parsing data at least includes a hash value of a previous block of the blockchain bytes;

[0076] A verification unit is configured to verify whether the hash value of the previous block is consistent with a hash value of a current block locally, and whether the virtual patch transaction bytes are in a block body of the blockchain;

[0077] A second synchronization unit is configured to, if the hash value of the previous block is consistent with the hash value of the current block locally, and the virtual patch transaction bytes are in the block body of the current block, perform synchronization processing on data in the block body by using a plurality of seed nodes in the blockchain; wherein the seed nodes refer to nodes in the blockchain that have a storage space greater than a preset threshold and an online duration greater than a preset duration;

[0078] A forwarding unit is configured to, after the synchronization processing is completed, forward the data synchronized by the seed nodes to backbone nodes respectively for each of the seed nodes, so that the backbone nodes forward the synchronized data; wherein the backbone nodes refer to nodes with a bandwidth not less than a preset bandwidth threshold and passing the node verification;

[0079] An updating unit is configured to, when a number of times of receiving data by the backbone nodes reaches a preset number of times, stop the forwarding operation of the backbone nodes, and update an association mapping table according to the virtual patch transaction bytes and position information of the block body.

[0080] Optionally, in the blockchain-based Internet of Things patch security distribution system, further comprising:

[0081] A judgment unit is configured to, when a monitoring instruction of a main network state is received, judge whether a core node triggers a master-backup switching; wherein the core node refers to a node in a main network of the blockchain that undertakes transaction processing and block propagation;

[0082] A stopping unit is configured to, if the core node triggers the master-backup switching, stop sending the data to the core node, and send the data to a high-reputation node in a sentinel node list for propagation; wherein the high-reputation node refers to a node with a forwarding success rate greater than a preset threshold and an offline duration not greater than a preset duration in a preset time period;

[0083] A connecting unit is configured to, after the propagation is completed, connect the core node with the main network and a sentinel network respectively, and acquire a hash value of the main network and a hash value of the sentinel network;

[0084] a comparison unit configured to compare the hash value of the main network and the hash value of the sentinel network;

[0085] a fourth acquisition unit configured to, if the hash value of the main network and the hash value of the sentinel network are inconsistent, locate a difference transaction by using a Merkle tree algorithm, and acquire a longest chain of the main network;

[0086] a correction unit configured to correct a local ledger according to the difference transaction and the longest chain.

[0087] The application provides a patch security distribution method based on a blockchain Internet of Things. Basic information and identity information of a device are acquired. Then, a vulnerability detection algorithm is used to detect whether there is vulnerability information corresponding to the basic information in a known vulnerability database. If there is vulnerability information corresponding to the basic information in the known vulnerability database, a virtual patch corresponding to the vulnerability information is acquired from a vulnerability patch database. Then, according to an identity identifier in the identity information, it is verified whether the identity information is valid. If the identity information is valid, the virtual patch is sent to the device, so that the device installs the virtual patch. Finally, after the device installs the virtual patch, the device is simulated in an isolated environment to simulate an attack behavior, and it is monitored whether the device successfully blocks the attack behavior. If the device successfully blocks the attack behavior, the virtual patch is sent to a similar device. The similar device refers to a device of the same type as the device. Thus, a unique and tamper-proof identity is given to each device according to the identity identifier, an attack on the identity of the device is effectively resisted, the problem that the identity of the device is difficult to authenticate is effectively solved, and it is also ensured that only the device that passes the identity verification can receive the virtual patch. BRIEF DESCRIPTION OF DRAWINGS

[0088] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description are only embodiments of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor on the basis of the provided drawings.

[0089] Figure 1 A flowchart of a patch security distribution method based on a blockchain Internet of Things provided by an embodiment of the present application is shown in the figure.

[0090] Figure 2 A flowchart of an identity information verification method provided by an embodiment of the present application is shown in the figure.

[0091] Figure 3 A flowchart of a result and record storage method provided by another embodiment of the present application is shown in the figure.

[0092] Figure 4A structural schematic diagram of a blockchain-based IoT patch security distribution system is provided for another embodiment of the present application. DETAILED DESCRIPTION

[0093] The technical solutions in the embodiments of the present application will be clearly and completely described in combination with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the present application.

[0094] In the present application, the relationship terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply that there is any such actual relationship or order between the entities or operations. Moreover, the terms “include”, “contain” or any other variants thereof are intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such process, method, article or device. Without more limitations, the element defined by the statement “including a…” does not exclude the presence of another identical element in the process, method, article or device including the element.

[0095] The embodiments of the present application provide 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, the embodiments of the present application provide a blockchain-based IoT patch security distribution system, which includes 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 diffusion module.

[0097] Specifically, the blockchain module plays a core role in the distribution system, which is used to record the key information of the whole process of patch generation, verification, issuance and deployment. Thus, through the distributed ledger technology of the blockchain, each operation step is recorded as an unalterable transaction record and stored and verified in multiple nodes in the blockchain network. This ensures that the patch source is credible, because all the generation and release information of the patch is permanently recorded and cannot be maliciously modified, and the process is traceable, so that when a security problem occurs or needs to be audited, the detailed information of each link from the generation to the deployment of the patch can be inquired through the blockchain.

[0098] The IoT device terminal is a proxy module for deploying virtual patches, which is responsible for receiving virtual patch rules issued by other components of the system and executing these rules on the device terminal. It is a key link for the implementation of virtual patches on IoT devices, and through interaction with the device operating system and related applications, it realizes the protection of device vulnerabilities. For example, when a device has a network protocol vulnerability, the virtual patch proxy module can intercept and modify related network packets to prevent malicious attacks from exploiting the vulnerability.

[0099] IoT cloud proxy platform: It plays an important role in centralized management of IoT devices. It establishes communication connection with IoT device terminals to collect detailed information of devices, including device model, manufacturer, hardware configuration, running operating system and firmware version, etc. Based on these information, IoT cloud proxy platform can accurately identify device type and firmware version. At the same time, it is also used to detect whether the device has known vulnerabilities.

[0100] Vulnerability patch database: It stores various device vulnerability information and corresponding virtual patch rules. These information is the basic data source for system vulnerability management and patch distribution. Vulnerability information includes vulnerability name, number, description, impact range, severity, etc. Virtual patch rules are specific protection strategies and operation instructions for each vulnerability, such as modifying system configuration parameters, intercepting specific types of network requests, etc. The database will be updated regularly to include newly discovered vulnerabilities and their corresponding patch rules, ensuring that the system can respond to changing security threats.

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

[0102] Identity authentication module: Based on the device identity (DID) of the blockchain, it realizes device identity registration, authentication and permission management. A unique decentralized identity (DID) is generated for each IoT device, and the DID information is written into the blockchain module to ensure the immutability and uniqueness of the identity information. When the device sends an identity authentication request, the identity authentication module extracts the DID and verifiable credentials (VC) from it, calls the smart contract interface of the blockchain module to verify the validity of the DID and the signature of the VC. According to the verification result, the device is granted or denied access to the virtual patch, and the authentication result (including device ID, authentication time, permission level) is written into the blockchain to form an immutable authentication record. For example, only devices that have passed identity authentication and have been granted appropriate permissions can receive and install specific virtual patches, effectively preventing the abuse of patches by malicious devices.

[0103] Patch verification module: deployed on the terminal of the Internet of Things device, used to simulate attack behavior to verify the effectiveness of the patch after deploying the patch on the device end.

[0104] Patch diffusion module: after the patch is verified to be effective, used to issue the virtual patch to other similar devices.

[0105] Based on the above-mentioned blockchain-based Internet of Things patch security distribution system, the embodiments of the present application correspondingly provide a blockchain-based Internet of Things patch security distribution method, as shown in the following Figure 1 The specific steps include the following steps:

[0106] S101, obtaining the basic information and identity information of the device.

[0107] It can be understood that the IoT cloud agent platform needs to establish a communication connection with the terminal of the Internet of Things device, and then the basic information of the device can be collected, wherein the basic information can include the device type, manufacturer, hardware configuration, operating system and firmware version of the device, etc.

[0108] The identity information is the information sent to the identity authentication module for identity authentication, so as to ensure the uniqueness of the device.

[0109] S102, using a vulnerability detection algorithm to detect whether there is vulnerability information corresponding to the basic information in the known vulnerability database.

[0110] It can be understood that in order to prevent malicious attacks from exploiting possible known vulnerabilities of the device to attack, the IoT cloud agent platform can first identify the device type and firmware version of the device based on the basic information of the device, and then use the vulnerability detection algorithm built-in the IoT cloud agent platform to detect whether there is vulnerability information corresponding to the basic information in the known vulnerability database, such as by comparing the firmware version of the device with the vulnerability information of the corresponding firmware version in the known vulnerability database, to determine whether the device is facing 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 known vulnerabilities, which need to be handled in time to achieve vulnerability protection of the device, so step S103 is executed.

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

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

[0113] Specifically, the vulnerability patch database stores various device vulnerability information and corresponding virtual patch rules, so when the known vulnerability database has the corresponding vulnerability information of the basic information, the vulnerability matching engine will automatically use an efficient matching algorithm to match the virtual patch in the vulnerability patch database according to the detected vulnerability information, so as to quickly and accurately filter out the applicable virtual patch from the huge database. For example, according to the vulnerability number, device type, firmware version and other key information, accurate query and association matching are performed in the database to determine the virtual patch rule most suitable for the device vulnerability.

[0114] S104, verifying whether the identity information is valid according to 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, and before sending the virtual patch to the device, the identity information of the device needs to be verified. Only when the identity information of the device is verified, the device can be granted the right to access the virtual patch, so as to prevent the patch from being misused by malicious devices. Therefore, in the embodiment of the present application, whether the identity information is valid will be 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, and therefore step S105 is executed.

[0116] Optionally, if the identity information is invalid, it means that the device may be a malicious device, and therefore the device is prohibited from sending the virtual patch.

[0117] Optionally, in another embodiment of the present application, a specific implementation of step S104 includes the following steps as shown in Figure 2

[0118] S201, extracting the identity identifier, binding information and signature of the verifiable credential of the device from the identity information.

[0119] It can be understood that the identity identifier is based on the device identity registration, authentication and permission management realized by the block chain, so as to generate a unique decentralized identity identifier (DID) for each Internet of Things device. Then the DID information, that is, the identity information, needs to be written into the block chain module, so as to ensure the non-tamperability and uniqueness of the identity information. Therefore, before sending the virtual patch to the device, the device needs to send the identity information to the identity authentication module, and then the identity authentication module will extract the DID of the device and the signature of the verifiable credential (VC) and the binding information. The binding information can include device hardware fingerprints (such as CPU serial number, MAC address hash), device public key and other information.

[0120] S202, detecting whether the identity identifier is registered on the block chain and whether it is in a valid state. ​

[0121] It can be understood that after the identity of the device, the binding information and the signature of the verifiable credential are extracted, the identity authentication module calls the smart contract interface of the blockchain module to query whether the identity is registered on the blockchain and whether it is in a valid state (not revoked, not expired). If the identity is registered on the blockchain and is in a valid state, step S203 is performed.

[0122] Optionally, if the identity is not registered on the blockchain and is not in a valid state, it is determined that the identity information of the device is invalid.

[0123] S203, detecting whether the identity and the binding information are consistent with the information recorded in the blockchain.

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

[0125] Optionally, if they are not consistent, it is determined that the identity information of the device is invalid.

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

[0127] It can be understood that when the identity and the binding information are consistent with the information recorded in the blockchain, the verifiable credential needs to be verified next. 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 later.

[0128] S205, verifying the signature using the public key, and determining that the identity information is valid when the signature is verified.

[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 is verified. If they are consistent, it is determined that the signature is verified. At this time, the device can be granted the right to access the virtual patch.

[0130] Optionally, if they are not consistent, it is determined that the signature is not verified, and therefore the identity information of the device is invalid, and the device is denied the right to access the virtual patch.

[0131] S105, sending the virtual patch to the device to make the device install the virtual patch.

[0132] It can be understood that when the identity information is valid, the system will send the virtual patch to the device to make the device deploy the virtual patch to prevent malicious attacks.

[0133] S106, after the device installs the virtual patch, simulate the attack behavior on the device in the 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, whether it can really resist malicious attacks, therefore, in the embodiment of the application, after the device deploys the virtual patch, the patch verification module receives and deploys the virtual patch issued by the virtual patch agent module, and simulates the attack behavior of the known vulnerability of the device in the isolated environment, so as to observe whether the device reconstructs the attack. Therefore, if the device successfully blocks the attack behavior, it means that the virtual patch is effective, and therefore step S107 is performed.

[0135] Optionally, if the device does not successfully block the attack behavior, it means that the virtual patch is invalid, at which time the patch rollback mechanism is triggered to restore the state of the device to the state before the patch is deployed, and an alarm information is generated and reported to the IoT cloud agent platform, so as to take further remedial measures in time.

[0136] S107, sending the virtual patch to the same type of device.

[0137] Among them, the same type of device refers to a device of the same type as the device.

[0138] It can be understood that when the device successfully blocks the attack behavior, the patch propagation module automatically issues the virtual patch to other Internet of Things devices of the same type as the device, so that the same type of device can prevent malicious attacks.

[0139] Specifically, since in the vulnerability patch database, each virtual patch is associated with metadata such as "applicable device type, firmware version, hardware model" (these metadata are recorded and stored when the patch is generated). When the patch propagation module reads the patch transaction record that has passed the verification from the blockchain, the applicable metadata of the patch rule is extracted, and then combined with the device DID registration information stored in the blockchain, including the device type, firmware version, and device information library synchronized with the IoT cloud agent platform for screening, and then according to the device type, firmware version, and other conditions applicable to the patch, the same type of device list is screened out. Then call the identity authentication module interface to confirm that the same type of device has the receiving permission from the same type of device list. After confirming the permission, the patch is batched and issued to the same type of device through the encrypted channel.

[0140] Optionally, in order to ensure that the verification result of the identity information is not tampered with and the record of issuing the virtual patch to the same type of device is traceable, therefore, in another embodiment of the application, a result and record storage method is also provided, as shown in Figure 3 The method specifically includes the following steps:

[0141] S301, obtaining a verification result of identity information and diffusion information of a virtual patch.

[0142] The diffusion information refers to information for sending the virtual patch to a same-type device.

[0143] Specifically, the verification result can include an id of the device, an authentication time, a permission level, and the like.

[0144] The diffusion information can include a target device list, a diffusion time, and a result status.

[0145] S302, storing the verification result and the diffusion information into a blockchain.

[0146] Optionally, in order to form an unalterable record of the verification result, the verification result can be written into the blockchain. In order to form a diffusion record of the diffusion information, improve patch coverage, and ensure that the diffusion process is auditable and traceable, the diffusion information of the virtual patch is written into the blockchain to form a diffusion record.

[0147] Optionally, the verification result of the validity of the virtual patch can also be encrypted and uploaded to an extension field of a patch transaction included in the blockchain.

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

[0149] A1: obtaining a data packet sent by a 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 that supports TCP / IP and UDP protocol adaptive switching. When communicating with the current blockchain core processing node and receiving a virtual patch transaction byte (the virtual patch transaction byte is generated when a patch-related operation is generated in the system, for example, a "patch delivery" transaction is generated when an IoT cloud agent platform prepares to deliver a patch, and a "patch verification result" transaction is generated when a patch verification module uploads a patch verification result) from a first peer node in the blockchain network, the other node will first filter damaged data packets through hardware-level CRC32 checking, so the virtual patch transaction byte will be filtered from the received data packet, and thus the sender will calculate the CRC32 value of the transaction byte and send it with the data packet, so that the system obtains the data packet sent by the sender. The data packet can include the virtual patch transaction byte and the corresponding verification value.

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

[0152] Specifically, when the system receives the virtual patch transaction byte, it recalculates the CRC32 value of the received virtual patch transaction byte, that is, the target check value, and compares it with the check value attached by the sender. If the check value is inconsistent with the target check value, process A3 is executed. If the check value is consistent with the target check value, process A4 is executed.

[0153] A3: If the check value is inconsistent with the target check value, the data packet is discarded.

[0154] It can be understood that when the check value is inconsistent with the target check value, the system will determine that the data packet sent by the sender is an undamaged data packet, and will discard the data packet to avoid occupying memory space.

[0155] A4: If the check value is consistent with the target check value, the data packet is parsed to obtain parsed data, and based on the parsed data, it is verified whether the virtual patch is complete and matches the device.

[0156] Specifically, when the check value is consistent with the target check value, the valid data is transmitted into the processor of the blockchain module. Since the data in the data packet has been pre-processed by structured packaging, the data packet is first parsed to obtain the patch hash value generated by the SHA-256 algorithm, the three-level device type field covering the hardware model (such as RK3588, Inteli7-13700K), the operating system kernel version (such as Linux 5.15.0, Android 13) and the firmware version number, so as to facilitate the core processing node to quickly select the adaptive node and the timestamp encrypted by the elliptic curve encryption (ECC secp256k1). After obtaining these parsed data, the system verifies whether the virtual patch is complete and matches the device based on the parsed data, so as to perform the propagation processing of the virtual patch. Therefore, if the virtual patch is complete and matches the device, process A5 is executed.

[0157] Alternatively, if the virtual patch is not complete and does not match the device, the propagation processing of the virtual patch cannot be performed, and the transaction processing of this time is also terminated.

[0158] A5: If the virtual patch is complete and matches the device, the virtual patch transaction byte is synchronized by using multiple delay nodes, and the virtual patch transaction byte is fragmented to obtain multiple fragment nodes.

[0159] Among them, the first fragment node carries the fragment serial number and the total number of fragments.

[0160] Specifically, when the virtual patch is complete and matches the device, it indicates that the virtual patch can be propagated, so in the propagation stage of the transaction, the processor starts the distributed propagation engine, based on the preset network topology map, using an improved Gossip protocol: in the initial stage, 3-5 low-delay neighbor nodes (the delay threshold is set to 50 ms) are synchronized with the virtual patch transaction bytes, that is, multiple delay nodes synchronize the virtual patch transaction bytes, and the processor will perform sharding processing on the transaction bytes to obtain multiple shard nodes, wherein the size of each shard is controlled within 1MB, and the shard header carries the shard serial number and the total number of shards, so as to utilize the shard nodes for propagation.

[0161] A6: sequentially send each shard node to the sender, so that the sender reassembles according to each shard node, and records the confirmation signal of each shard node.

[0162] It can be understood that after obtaining all the shard nodes, the nodes with a response rate of more than 95% in the past 10 minutes are preferentially selected. The key calculation details are as follows, the edge weight wij is determined by RTT, jitter and packet loss rate, wherein σij is the RTT jitter standard deviation, and pij is the packet loss rate (0-1).

[0163]

[0164] wherein, RTT represents the round-trip time between node i and node j, reflecting the network delay.

[0165] Execute constrained Dijkstra:

[0166]

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

[0168] Update neighbor weight every 100 ms:

[0169]

[0170] wherein, Sent i represents the total number of transaction shards sent to neighbor node i, and Ack i represents the number of ACKs returned by neighbor node i.

[0171] The sampling probability is normalized:

[0172]

[0173] wherein, ω i The forwarding weight of neighbor node i is a comprehensive response rate and delay, ω iThe larger, the more efficient node forwarding, the more priority to be selected into the forwarding list.

[0174] If R i <0.95 or RTT i > 50 ms, among the neighbor nodes of the blockchain core processing node currently participating in the Gossip protocol forwarding, the node satisfying the condition of "R i <0.95" or "RTT i > 50 ms" (wherein, Ri is the receiving confirmation rate of the node, i.e. the number of Acks / the number of sending. RTTi is the round trip time of the node). Immediately downgraded to passive relay, stop the next round of Gossip. At the same time, the processor will send each shard node to the sender in turn, so that the sender reassembles according to each shard node. Whenever the sender receives a shard node, the sender records the confirmation signal of the received shard node, so as to send each confirmation signal to the receiver.

[0175] A7: Obtain multiple confirmation signals, and determine whether the sender receives all shard nodes according to each confirmation signal.

[0176] Specifically, the receiver will receive the confirmation signal of each shard node received by the sender, and in order to know whether the sender receives all shard nodes, it is also necessary to determine whether the sender receives all shard nodes according to each confirmation signal. If the sender receives all shard nodes, process A8 is executed, and if the sender does not receive all shard nodes, process A9 is executed.

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

[0178] It can be understood that when the sender receives all shard nodes, the processor will package the virtual patch transaction bytes, and store the packaged virtual patch transaction bytes in the blockchain bytes of the blockchain, so as to wait for the next step of processing.

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

[0180] Specifically, when the sender does not receive all shard nodes, the retransmission mechanism of the shard node that is not successfully sent will be triggered, i.e. the retransmission interval is increased according to the exponential backoff algorithm for retransmission.

[0181] Optionally, after the virtual patch transaction bytes are packaged into the blockchain bytes of the blockchain, the transceiver of the blockchain module will further diffuse the blockchain bytes. Therefore, in another embodiment of the present application, a diffusion method of blockchain bytes is also provided, which includes specific processes B1 to B5:

[0182] B1: Obtain the blockchain bytes and perform parsing processing on the blockchain bytes to obtain target parsing data.

[0183] Specifically, when the transceiver receives the blockchain bytes containing the virtual patch transaction bytes from the second peer node, the target parsing data is generated when the corresponding operation is performed by the functional module in the system, for example, the patch delivery transaction is generated when the Iot cloud agent platform initiates the patch delivery operation. After these transactions are generated, they will be propagated in the blockchain network, then packaged into a block to form blockchain bytes containing the transaction, and then the blockchain bytes are parsed to obtain target parsing data. The target parsing data can include the block header containing the previous block hash (32 bytes), the Merkle root (32 bytes), the timestamp (64 bits), the difficulty value (32 bits), and the random number (32 bits). The block body stores the serialized data of the transaction and other 100-500 transactions in a linked list form.

[0184] B2: Verify whether the hash value of the previous block is consistent with the hash value of the current block locally, and whether the virtual patch transaction bytes are in the block body of the blockchain.

[0185] It can be understood that after obtaining the target parsing data, the processor will start a parallel verification thread: on the one hand, the consistency of the previous block hash and the latest block hash of the local ledger is verified, and on the other hand, it is verified through the Merkle tree path whether the virtual patch transaction bytes really exist in the block body. The verification time is controlled within 200ms, so that the propagation of the blockchain bytes starts to adopt a hierarchical diffusion strategy. Therefore, if the hash value of the previous block is consistent with the hash value of the current block locally, and the virtual patch transaction bytes are in the block body of the current block, the hierarchical diffusion strategy can be started at this time, and therefore process B3 is executed.

[0186] Alternatively, if the hash value of the previous block is not consistent with the hash value of the current block locally, and the virtual patch transaction bytes are not in the block body of the blockchain, no operation is needed or the blockchain bytes are deleted from the blockchain.

[0187] B3: If the hash value of the previous block is consistent with the hash value of the current block locally, and the virtual patch transaction bytes are in the block body of the current block, then the data in the block body is synchronized by using multiple seed nodes in the blockchain.

[0188] Among them, the seed node refers to a node whose storage space in the blockchain is greater than a preset threshold, and the online duration is greater than a preset duration.

[0189] Specifically, when the hash value of the current sequence 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 synchronizes complete block data to three seed nodes in the network first, the seed nodes need to meet the storage space of more than 1TB and the online time of more than 90%, and then the seed nodes are diffused in levels according to the "backbone node-edge node" hierarchy, so the data in the block body needs to be synchronized by multiple seed nodes in the blockchain first, and then the hierarchical diffusion processing is performed by the seed nodes.

[0190] B4: After the synchronization processing is completed, the data synchronized by the seed node is forwarded to the backbone node for each seed node respectively, so that the backbone node forwards the synchronized data.

[0191] Among them, the backbone node refers to a node with a bandwidth not less than a preset bandwidth threshold and passing the node check.

[0192] It should be noted that after the seed node synchronizes the data, the seed node then diffuses in levels according to the "backbone node-edge node" hierarchy, so the backbone node needs to be selected first. The identification of the backbone node in the blockchain network is based on the "node attribute declaration + network verification" mechanism. Specifically, when the node accesses the network, it actively declares its hardware resource attributes (such as bandwidth ≥ 1Gbps, storage space ≥ 500GB, online time commitment ≥ 80%, etc.) to the seed node or core node. The seed node checks the resource (such as detecting the actual bandwidth, counting the online time, etc.) of the node declared as "backbone node candidate" every 1 hour or so. The node passing the verification will be marked as "backbone node", and its node ID, public key, resource attribute and other information will be written into the "node attribute transaction" of the blockchain for network query and synchronization. If the backbone node appears to be out of standard in terms of bandwidth reduction, online time shortage, etc. in the future, the seed node will initiate a "backbone node degradation" transaction to remove it, so as to dynamically maintain the resource of the backbone node to meet the diffusion demand. Therefore, after the backbone node is selected, the seed node sends its synchronized data to the backbone node for forwarding and diffusion.

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

[0194] It should be noted that in the embodiments of the present application, the seed node needs to forward 3 same block data to the backbone node, and the 3 same block data is the result of the distributed propagation characteristics of the blockchain network, that is, after the consensus node of the blockchain generates a new block, it synchronizes the block data to 3-5 neighbor nodes (including seed nodes, other consensus nodes, etc.) connected to itself first, and then the node receiving the initial block data (such as the seed node) forwards 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, and eventually the backbone node receives multiple block data with consistent content hash from different upstream nodes (seed nodes, other core nodes, etc.) within a short time (such as within 100 ms).

[0195] Therefore, when the receiving times of the backbone node reach 3 times, 3 same block data are obtained, at this time it is determined that the block has been initially diffused in the network, and the backbone node will stop forwarding to avoid wasting network bandwidth.

[0196] Finally, after the diffusion is completed, the processor needs to update the association mapping table, that is, the built-in transaction-block association mapping table. When the virtual patch transaction byte and the corresponding block byte are both verified, the local ledger index will be automatically updated, the patch transaction and the block position information (block height, offset of transaction in block) are bound, which is convenient for subsequent query and traceability.

[0197] Optionally, the blockchain module also involves the master-backup switching of the sentinel network, which is designed to counteract the discriminatory forwarding of centralized nodes. Therefore, in another embodiment of the present application, a master-backup switching method of the sentinel network is also provided, which includes specific processes C1 to C6:

[0198] C1: When receiving a monitoring instruction of the main network state, it is determined whether the core node triggers the master-backup switching.

[0199] Among them, the core node refers to the node that undertakes transaction processing and block propagation in the main network of the blockchain.

[0200] Specifically, when receiving a monitoring instruction of the main network state, the sentinel network core processing node will start the king state detection engine to determine whether the core node triggers the master-backup switching. The processor is built-in with a "main network state monitoring engine" to compare the transaction forwarding efficiency of the nodes that undertake the core responsibilities of transaction processing and block propagation in the core nodes of the blockchain main network and the sentinel nodes in real time: sample the main network transaction response time (the interval from sending to receiving ACK) every 500 ms, when the sampling value is more than 2 times the average response time of the sentinel network for 3 times in a row, or the transaction forwarding success rate of the main network node to a specific device type field is detected to be less than 60%, the "master-backup switching" is automatically triggered, so process C2 needs to be executed next.

[0201] Optionally, if the core node does not trigger the master-backup switching, the monitoring is continued.

[0202] In addition, the sentinel network in the blockchain module is a decentralized backup channel, and the core processing node thereof includes an independent processor and an enhanced transceiver, which are specially designed to resist the discriminatory forwarding of the centralized node. The specific mechanism is as follows: the transceiver adopts a "master-slave dual-band communication module", which supports a decentralized discovery protocol superimposed on the basis of the original TCP / UDP protocol: a new node needs to pass through "sentinel qualification verification" to submit its public key, network behavior log in the past 72 hours, and hardware resource proof to three authenticated sentinel nodes. If more than two of the three authenticated sentinel nodes determine that the verification is passed, a "sentinel node authentication credential" (including the signature of the three nodes) is generated and fed back to the new node. If the verification is not passed, the new node is informed of the reason (such as insufficient resources, abnormal log). After the verification is passed, the node is added to the sentinel node list, which is updated every 10 minutes through a distributed hash table. The authenticated sentinel node information of the sentinel network in the blockchain module can be obtained through the three mechanisms of "distributed hash table real-time query + blockchain on-chain tracing + local cache synchronization": the DHT maintains an "authenticated sentinel node list" containing node public key hash, communication address and qualification validity period and is automatically updated every 10 minutes, supporting nodes to query real-time information with "sentinel_node_list" as the key. The blockchain stores the "sentinel node authentication transaction" (containing the node public key, hardware resource proof digest and the signature of the three authentication nodes) of the authenticated node for tracing to avoid the risk of DHT tampering. The blockchain core processing node synchronizes the list from the DHT every 5 minutes and caches it locally to provide online nodes with good status for the new node to select when initiating sentinel qualification verification to improve interaction efficiency. The transceiver listens to a dedicated port by default to avoid port blocking. The processor enables double encryption for the transmitted virtual patch transactions and blockchain bytes: the outer layer uses the ChaCha20-Poly1305 algorithm to encrypt the transmission frame, and the inner layer retains the original ECC encryption layer of the blockchain. At the same time, all traceable node meta information (such as MAC address, IP geographic marker) in the data packet is stripped, and only the node public key hash is retained. The transceiver adopts a "random delay forwarding strategy" when forwarding, adds a random delay of 10-50 ms to each data packet, and avoids traffic feature analysis.

[0203] C2: If the core node triggers the master-backup switching, stop sending data to the core node, and send the data to the high-reputation nodes in the sentinel node list for propagation.

[0204] Among them, the high-reputation node refers to a node whose forwarding success rate is greater than a preset threshold in a preset time period, and whose offline duration is not greater than a preset duration.

[0205] Specifically, when the core node triggers the master-slave switching, after the switching, the transceiver immediately stops sending data to the core node of the master network, and instead transmits through the "high reputation nodes" (the forwarding success rate is greater than or equal to 98% in the past 24 hours, and the offline duration is less than or equal to 5 minutes) in the sentinel node list. The initial number of synchronization nodes is set to 5-8 (higher than the master network, to improve the anti-node failure capability).

[0206] C3: After the propagation is completed, the core node is connected with the master network and the sentinel network respectively, and the hash value of the master network and the hash value of the sentinel network are obtained.

[0207] Specifically, after the propagation is completed, the sentinel network and the master network will adopt a "double write check mechanism": when the core node has the ability to access the master network and the sentinel network at the same time, and can establish communication connection with the master network node and the sentinel network node at the same time, and bear the data synchronization and check responsibility, the processor will subsequently compare the blockchain bytes received by the two types of networks, so it is necessary to obtain the hash value of the master network and the hash value of the sentinel network.

[0208] C4: Compare whether the hash value of the master network and the hash value of the sentinel network are consistent.

[0209] It can be understood that after obtaining the hash value of the master network and the hash value of the sentinel network, the processor will compare the blockchain bytes received by the two types of networks, and if the hash value of the master network and the hash value of the sentinel network are inconsistent (allowing temporary bifurcation within 2 blocks), the bifurcation repair process is started, that is, process C5 is executed.

[0210] Optionally, if the hash value of the master network and the hash value of the sentinel network are consistent, it is determined that the data in the master network and the sentinel network are consistent, at which time the local account book can be normally updated.

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

[0212] It should be noted that when the hash value of the main network and the hash value of the sentinel network are inconsistent, the difference transactions are compared layer by layer through the Merkle tree to correct the local ledger according to the longest chain of the main network, but the backup (storage time 7 days) of the sentinel network fork block is retained for tracing the main network exception. Therefore, when the sentinel network block and the main network block hash are inconsistent, the Merkle root of the main network block and the sentinel network block is extracted first, and then the Merkle root of the main network block and the sentinel network block is compared. If the two are inconsistent, the Merkle tree level structure corresponding to the two blocks is obtained, and the hash values are compared from the next layer of child nodes of the root node, the branches without difference are excluded, the sub-tree with difference is focused on, and the recursion comparison is performed layer by layer downward, until the leaf node layer of the Merkle tree (each node of the layer corresponds to the SHA-256 hash of a transaction), so as to locate the specific difference transaction, and then the length of the main network chain to which the Block_M belongs and the length of the sentinel network chain to which the Block_S belongs are compared to obtain the longest chain of the main network.

[0213] C6: Correcting the local ledger according to the difference transaction and the longest chain.

[0214] It can be understood that after the difference transaction and the longest chain are obtained, the difference transaction and the longest chain are used as the corrected local ledger (the transactions consistent with the "non-longest chain" in the local are deleted and replaced with the transactions of the longest chain), and the backup of the sentinel network fork block is retained for tracing the main network exception.

[0215] The application provides a blockchain-based IoT patch security distribution method. By obtaining the basic information and identity information of the device, the application detects whether there is corresponding vulnerability information in the known vulnerability database using a vulnerability detection algorithm. If there is corresponding vulnerability information in the known vulnerability database, the application obtains the virtual patch corresponding to the vulnerability information from the vulnerability patch database, and then verifies whether the identity information is valid according to the identity identifier in the identity information. If the identity information is valid, the application sends the virtual patch to the device to enable the device to install the virtual patch. Finally, the application simulates an attack behavior on the device in an isolated environment after the device installs the virtual patch, and monitors whether the device successfully blocks the attack behavior. If the device successfully blocks the attack behavior, the application sends the virtual patch to the same type of device. The same type of device refers to a device of the same type as the device. Thus, the identity identifier is assigned to each device to effectively resist attacks on the device identity, effectively solve the problem of difficult authentication of the device identity, and ensure that only devices that pass the identity verification can receive the virtual patch.

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

[0217] The information acquisition unit 401 is configured to acquire basic information and identity information of the device.

[0218] The vulnerability detection unit 402 is configured to detect, by using a vulnerability detection algorithm, whether there is vulnerability information corresponding to the basic information in a known vulnerability database.

[0219] The patch acquisition unit 403 is configured to acquire, if there is vulnerability information corresponding to the basic information in the known vulnerability database, a virtual patch corresponding to the vulnerability information from a vulnerability patch database.

[0220] The identity verification unit 404 is configured to verify, according to an identity identifier in the identity information, whether the identity information is valid.

[0221] The patch sending unit 405 is configured to send, if the identity information is valid, the virtual patch to the device, so that the device installs the virtual patch.

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

[0223] The patch distribution unit 407 is configured to send, if the device successfully blocks the attack behavior, the virtual patch to a same-type device. The same-type device refers to a device of the same type as the device.

[0224] It should be noted that the specific working process of the above modules in the embodiments of the present application can correspondingly refer to steps S101-S107 in the above method embodiments, which will not be described here.

[0225] Optionally, another embodiment of the present application provides a patch security distribution system based on a blockchain in an Internet of Things, wherein the identity verification unit 404 comprises:

[0226] The extraction unit is configured to extract an identity identifier, binding information, and a signature of a verifiable credential of the device from the identity information.

[0227] The identifier detection unit is configured to detect whether the identity identifier is registered on the blockchain and is in a valid state.

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

[0229] The public key extraction unit is configured to extract, if the identity identifier and the binding information are consistent with the information of the device recorded in the blockchain, a public key of the verifiable credential from the blockchain.

[0230] The signature verification unit is configured to verify the signature by using the public key, and determine that the identity information is valid when the signature is verified.

[0231] Optionally, another embodiment of the present application provides a blockchain-based IoT patch security distribution system, further comprising:

[0232] The first obtaining unit is configured to obtain a verification result of the identity information and diffusion information of the virtual patch. The diffusion information refers to information for sending the virtual patch to devices of the same type.

[0233] The storage unit is configured to store the verification result and the diffusion information in the blockchain.

[0234] Optionally, another embodiment of the present application provides a blockchain-based IoT patch security distribution system, further comprising:

[0235] The second obtaining unit is configured to obtain a data packet sent by the sender. The data packet at least includes a virtual patch transaction byte and a corresponding verification value thereof.

[0236] The calculation unit is configured to calculate a 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 configured to perform packet loss processing on the data packet if the verification value is not consistent with the target verification value.

[0238] The verification unit is configured to analyze the data packet to obtain analysis data if the verification value is consistent with the target verification value, and verify whether the virtual patch is complete and matches the device based on the analysis data.

[0239] The first synchronization unit is configured to synchronize the virtual patch transaction byte by using a plurality of delay nodes if the virtual patch is complete and matches the device, and perform fragmentation processing on the virtual patch transaction byte to obtain a plurality of fragment nodes. The first fragment node carries a fragment serial number and a total number of fragments.

[0240] The recombination unit is configured to sequentially send each fragment node to the sender, so that the sender recombines according to each fragment node, and records an acknowledgement signal of each fragment node.

[0241] The node judgment unit is configured to obtain a plurality of acknowledgement signals, and determine whether the sender receives all the fragment nodes according to each acknowledgement signal.

[0242] The packaging unit is configured to package the virtual patch transaction byte if the sender receives all the fragment nodes, and store the packaged virtual patch transaction byte in the blockchain byte.

[0243] The triggering unit is configured to trigger a retransmission mechanism if the sender does not receive all the fragment nodes.

[0244] Optionally, another embodiment of the present application provides a blockchain-based Internet of Things patch security distribution system, further comprising:

[0245] The third acquisition unit is configured to acquire blockchain bytes and perform parsing processing on the blockchain bytes to obtain target parsing data. The target parsing data at least includes a hash value of a previous block of the blockchain bytes.

[0246] The verification unit is configured to verify whether the hash value of the previous block is consistent with a hash value of a current block locally, and whether the virtual patch transaction byte is in a block body of the blockchain.

[0247] The second synchronization unit is configured to, if the hash value of the previous block is consistent with the hash value of the current block locally, and the virtual patch transaction byte is in the block body of the current block, perform synchronization processing on data in the block body by using a plurality of seed nodes in the blockchain. The seed node refers to a node in the blockchain that has a storage space greater than a preset threshold and an online duration greater than a preset duration.

[0248] The forwarding unit is configured to, after the synchronization processing is completed, forward the data synchronized by the seed node to a backbone node for each seed node, so that the backbone node forwards the synchronized data. The backbone node refers to a node with a bandwidth not less than a preset bandwidth threshold and passing a node verification.

[0249] The updating unit is configured to, when the number of times of receiving data by the backbone node reaches a preset number of times, stop the forwarding operation of the backbone node, and update an association mapping table according to the position information of the virtual patch transaction byte and the block body.

[0250] Optionally, another embodiment of the present application provides a blockchain-based Internet of Things patch security distribution system, further comprising:

[0251] The judgment unit is configured to, when receiving a monitoring instruction of a main network state, judge whether a core node triggers a master-slave switching. The core node refers to a node in a main network of the blockchain that undertakes transaction processing and block propagation.

[0252] The stopping unit is configured to, if the core node triggers the master-slave switching, stop sending data to the core node, and send the data to a high-reputation node in a sentinel node list for propagation. The high-reputation node refers to a node with a forwarding success rate greater than a preset threshold and an offline duration not greater than a preset duration in a preset time period.

[0253] The connecting unit is configured to connect the core node with the main network and the sentinel network respectively after the propagation is completed, and obtain a hash value of the main network and a hash value of the sentinel network.

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

[0255] The fourth obtaining unit is configured to, if the hash value of the main network and the hash value of the sentinel network are inconsistent, locate a difference transaction by using a Merkle tree algorithm, and obtain a longest chain of the main network.

[0256] The correcting unit is configured to correct a local ledger according to the difference transaction and the longest chain.

[0257] It should be noted that the specific working processes of the various units provided in the above embodiments of the present application can be correspondingly referred to the corresponding steps in the above method embodiments, which will not be described here.

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

[0259] The skilled person can further realize that the units and algorithm steps of the examples described in conjunction with the disclosed embodiments can be realized in electronic hardware, computer software or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the components and steps of the examples have been described in the above description in general terms. Whether the functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. The skilled person can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0260] The above description of the disclosed embodiments enables a person skilled in the art to implement or use the present application. Various modifications to the embodiments will be apparent to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to 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.

2. The method according to claim 1, characterized in that, 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.

3. The method according to claim 1, characterized in that, Also includes: 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.

4. 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.

5. The method according to claim 4, 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.

6. The method according to any one of claims 1 to 5, 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 value of the main network and the hash value of 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.

7. 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 use vulnerability detection algorithms to detect whether the vulnerability information corresponding to the basic information exists in the known vulnerability database; 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.

8. The system according to claim 7, characterized in that, 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.

9. The system according to claim 7, characterized in that, 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 diffusion information into the blockchain.

10. The system according to claim 7, 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