WO2021036545A1 - 一种基于智能合约的数据处理方法、设备及存储介质 - Google Patents
一种基于智能合约的数据处理方法、设备及存储介质 Download PDFInfo
- Publication number
- WO2021036545A1 WO2021036545A1 PCT/CN2020/101558 CN2020101558W WO2021036545A1 WO 2021036545 A1 WO2021036545 A1 WO 2021036545A1 CN 2020101558 W CN2020101558 W CN 2020101558W WO 2021036545 A1 WO2021036545 A1 WO 2021036545A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- version
- firmware
- update
- node
- record
- Prior art date
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2379—Updates performed during online database operations; commit processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
- G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
- H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
- H04L41/082—Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/085—Retrieval of network configuration; Tracking network configuration history
- H04L41/0859—Retrieval of network configuration; Tracking network configuration history by keeping history of different configuration generations or by rolling back to previous configuration versions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
- H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
- G06F2221/033—Test or assess software
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Definitions
- This application relates to the field of Internet technology, and in particular to a data processing method, equipment and storage medium based on smart contracts.
- Server firmware refers to the program written into the EPROM (erasable programmable read-only memory) or EEPROM (electrically erasable programmable read-only memory) of the server. It should be understood that the server firmware can store the basic parameters and programs of the hardware devices in the corresponding operating system, which can provide the lowest level and most direct hardware control for the operating system.
- server operation and maintenance personnel can update the server's firmware (for example, BIOS (Basic Input Output System) firmware) through offline analysis, in-band network or system management interruption and other firmware update methods to increase New features of the operating system or repair of anomalies of the operating system.
- firmware for example, BIOS (Basic Input Output System) firmware
- the embodiments of the present application provide a data processing method, device, and storage medium based on smart contracts, which can improve the security and reliability of firmware updates.
- the firmware update request includes at least: an update version parameter of the first server node;
- the smart contract is called according to the firmware update request, and the firmware version update record and the firmware version release record associated with the first server node are obtained from the blockchain based on the smart contract; the firmware version release record is the The publishing nodes on the blockchain are determined based on the consensus mechanism;
- the embodiment of the application provides a data processing device based on a smart contract.
- the device is applied to a contract node and includes:
- the request receiving module is configured to receive a firmware update request for the first server node sent by the execution node; the firmware update request includes at least: the update version parameter of the first server node;
- the contract call module is used to call a smart contract according to the firmware update request, and obtain a firmware version update record and a firmware version release record associated with the first server node from the blockchain based on the smart contract; the firmware The version release record is determined by the release node on the blockchain based on the consensus mechanism;
- the legality determination module is configured to determine the legality of the firmware update request according to the firmware version update record, the firmware version release record, and the update version parameter.
- the embodiment of the present application provides a node device, including: a processor and a memory;
- the processor is connected to a memory, where the memory is used to store program code, and the processor is used to call the program code to perform the following operations:
- the smart contract is called according to the firmware update request, and the firmware version update record and the firmware version release record associated with the first server node are obtained from the blockchain based on the smart contract; the firmware version release record is the The publishing nodes on the blockchain are determined based on the consensus mechanism;
- the embodiment of the present application provides a computer storage medium, the computer storage medium stores a computer program, and the computer program includes program instructions.
- a processor executes the program instructions, it executes as described in any of the embodiments of the present application. method.
- Figure 1 is a schematic structural diagram of a blockchain network topology provided by an embodiment of the present application.
- FIG. 2 is a schematic flowchart of a data processing method based on a smart contract provided by an embodiment of the present application
- FIG. 3 is a schematic diagram of a block structure of a nested hash chain provided by an embodiment of the present application
- FIGS. 4a and 4b are schematic diagrams of performing version release control provided by an embodiment of the present application.
- FIG. 5 is a schematic flowchart of another data processing method based on smart contracts provided by an embodiment of the present application.
- FIG. 6 is a schematic diagram of obtaining version release behavior information provided by an embodiment of the present application.
- FIG. 7 is a schematic diagram of constructing a firmware version update record provided by an embodiment of the present application.
- FIG. 9 is a schematic structural diagram of a data processing device based on a smart contract provided by an embodiment of the present application.
- Fig. 10 is a schematic structural diagram of a node device provided by an embodiment of the present application.
- FIG. 1 is a schematic structural diagram of a blockchain network topology provided by an embodiment of the present application.
- the blockchain network topology shown in Figure 1 can be applied to the application scenario with large-scale servers in the enterprise intranet.
- the blockchain network topology structure may include the publishing layer 100, the contract layer 200, and the implementation layer 300 shown in FIG. 1.
- the nodes located in the publishing layer 100 may be referred to as publishing nodes, and specifically may include the publishing node 10a, the publishing node 10b, and the publishing node 10c shown in FIG. It should be understood that the publishing layer 100 may also include other publishing nodes (not shown in FIG. 1 for the time being).
- the nodes in the contract layer 200 can be collectively referred to as contract nodes, which can be understood as nodes in the blockchain that can call and execute smart contracts stored in the blockchain.
- the contract The layer 200 may include the contract node 20a and the contract node 20b shown in FIG. 1. As shown in FIG.
- the nodes in the implementation layer 300 are mainly composed of two types of nodes, one of the two types of nodes may be called execution nodes, and the other type of nodes may be called server nodes.
- the execution node may specifically include the execution node 30a and the execution node 30b shown in FIG. 1; similarly, the server node may specifically include the server node 40a, the server node 40b, and the server node 40c shown in FIG.
- the publishing nodes, contract nodes, execution nodes, and server nodes located in the blockchain network topology can be collectively referred to as nodes in the blockchain network.
- these nodes can be fully connected.
- the first network connection between the publishing node 10a and the contract node 20a shown in FIG. 1 can be called full connection, which is the implementation of this application.
- the network connection that can be connected within one hop is called full connection.
- the nodes in the blockchain may also be connected through a physical network.
- the second network connection between the contract node 20a and the contract node 20b shown in FIG. 1 may need to be connected through a physical network.
- a network connection (for example, a virtual network card), that is, a network connection that cannot be connected within one hop, can be referred to as a physical network connection through a physical network.
- the publishing node 10a as shown in FIG. 1 can receive the latest version of the firmware file (for example, firmware file x) released by the manufacturer (for example, the manufacturer A). Further, the publishing node 10a may analyze the file structure of the acquired firmware file x to further determine the internal version number of the firmware text x (for example, the latest firmware version number AAAA) according to the file content in the firmware file x, and calculate The hash value corresponding to the version number (for example, hash value 1). Further, as shown in Figure 1, the release node 10a in the blockchain network can release the firmware version release parameters of the manufacturer A (ie the latest firmware version) to the adjacent contract node 20a through the full connection with the contract node 20a.
- the firmware version release parameters of the manufacturer A ie the latest firmware version
- the contract node can propagate the release parameters of the manufacturer A's version to other contract nodes in the contract layer 200 (for example, the contract node 20b).
- the release node in the embodiment of the present application can broadcast the firmware version release parameters released by the manufacturer A (ie, the firmware version number AAAA and the hash value 1) to all contract nodes in the contract layer 200.
- the publishing node 10a publishes the firmware version publishing parameters to the contract node 20a, it can sign the firmware version publishing parameters with its own private key, and can combine the signed information with the public of the publishing node 10a.
- the key is used as the version release confirmation information, so that the version release confirmation information can be given to the contract node 20a together, so that the contract node 20a can complete the consensus on the blockchain through the time threshold mechanism (that is, within the preset time window T) .
- the consensus of the blockchain can be limited to the contract nodes in the contract layer 200.
- the contract node 20a after the contract node 20a receives the version release confirmation message sent by the publishing node 10a, it can wait within a preset time window T, if there are other publishing nodes in the time window T (for example, as shown in Figure 1
- the release node 10b) also broadcasts the same firmware version release parameters, which indirectly indicates that a consensus has been reached between the release nodes.
- the contract node can write the firmware version release record containing the release parameters of the version into the blockchain to ensure Reach a contractual consensus.
- the firmware version release parameters released by the manufacturer A released by other release nodes are received at other times outside the time window T, it indirectly indicates that the version release parameters released by the manufacturer A are not recognized.
- the contract nodes in the contract layer 200 can communicate through the physical network, after the contract node 20a receives the block containing the version release parameters, the block containing the version release parameters can be Synchronize between the contract nodes to further reach a contract consensus, that is, the embodiment of this application can also effectively judge the version release parameters released by the manufacturer A on the blockchain through the consensus mechanism (ie, the firmware version number AAAA and Harbin). Hope value 1) is the latest version of the manufacturer's firmware information.
- the blockchain described in the embodiments of the present application is a special distributed database, which may also be referred to as a distributed ledger system.
- the distributed database i.e. blockchain
- the distributed database can have the following two functions: one is to store information, that is, nodes on the blockchain can store any information that needs to be saved, after reaching a consensus through the aforementioned time threshold mechanism Write to the blockchain, and can reach a contract consensus on the blockchain through a consensus mechanism.
- the consensus mechanism here can also include: Proof of Work (PoW), Proof of Stake (PoS), Practical Byzantine Fault Tolerance (PBFT), etc., which will not be limited here; Second, anyone can set up a server and join the zone The blockchain network becomes a node.
- the distributed ledger system can be understood as an asset database that can be shared in a blockchain network composed of multiple sites, different geographic locations, or multiple institutions. Participants in a blockchain network can obtain a unique, true copy of the ledger. Any changes in the ledger will be reflected in all copies, and the reaction time can be within minutes or even seconds.
- the consensus of the blockchain that is, the consensus between publishing nodes and the consensus between contract nodes
- the execution of smart contracts can be limited to specific contract nodes.
- the smart contract described in this application refers to a firmware update contract jointly participated by the executor of the update operation (for example, the execution node 30a shown in FIG. 1) and the updated server (that is, the server node 40a shown in FIG.
- the firmware update contract can be used to instruct the contract node 20a to obtain a firmware update request (ie a firmware update request) from the execution node 30a to the server node 40a (ie, the first server node) by obtaining it from the blockchain
- the obtained firmware version update records, firmware version release records, and update version parameters in the firmware update request associated with the first server node are used to determine the legitimacy of the firmware update request sent by the execution node 30a.
- the embodiment of the present application shows that when the contract node 20a determines that the firmware update request is a legal update request, the execution node 30a may be permitted to update the running version parameters of the first server node based on the updated version parameters; otherwise, Then the execution node cannot update the firmware of the first server node. It can be seen that by invoking the smart contract, legal and illegal firmware update operations can be effectively distinguished, so that illegal firmware updates can be avoided, and the security and reliability of firmware updates can be effectively improved.
- the block chain may be composed of blocks in the block structure, and these block chains composed of blocks may be called nested hash chains. , That is, each block in the nested hash chain will contain the hash of the previous block and multiple histories of firmware update for the first server node (for example, the server node 40a shown in FIG. 1) Version update behavior information, and version update records containing these historical version update behavior information can be collectively referred to as firmware version update records.
- the blocks in the embodiments of the present application may include corresponding firmware version update records; in the embodiments of the present application, the blocks may also include corresponding firmware version release records.
- the embodiment of the present application may collectively refer to the block containing the firmware version update record as the first block, and may refer to the block containing the firmware version release record as the second block.
- the first block may include a firmware version update record
- the version update behavior information in the firmware version update record may carry a first version parameter and a second version parameter
- the second version parameter is a comparison to the first version Parameter version parameter after firmware update.
- the firmware version update record can be used to record version update behavior information of the behavior of updating the firmware version information of the first server node. If multiple firmwares in the first server node have completed firmware update operations, multiple historical version update behavior information can be generated.
- the firmware version update records corresponding to all legal firmware update operations and the firmware version release records corresponding to the version release operations in the embodiments of this application can be recorded in the blockchain, so that subsequent release nodes can query each on the chain.
- the security status of the server node for example, the off-chain firmware information and the on-chain firmware information of each server node can be security audited, so that suspected abnormal server nodes can be found out of large-scale server nodes for alarms, which can be used
- the corresponding emergency response process for example, can isolate suspected abnormal servers from the network, which can effectively improve the perception of illegal intrusion methods, thereby significantly increasing the security of the corporate intranet.
- the execution node 30a may send a firmware update request to the contract node 20a shown in FIG. 1 before performing the firmware update for the server node 40a (that is, the first server node). Therefore, when the contract node 20a determines that the firmware update request is a legal update request, the execution node 30a can be permitted to perform the firmware update.
- the firmware update is performed on the first server node (for example, the server node 40b shown in FIG.
- a new firmware version update record may be generated, and the block containing the new firmware version update record may be Call it the new first block, so that the new first block can be written into the blockchain in an orderly manner, so that subsequent publishing nodes can access the first server node on the blockchain.
- Security status is audited. That is, the publishing node can perform the security status of the first server node based on the on-chain firmware information of the first server node stored in the first block in the blockchain and the off-chain firmware information collected locally. Evaluation. If the two are consistent, the normal value can be returned. Otherwise, it means that the security status of the first server node is abnormal.
- the publishing node can notify the first server by means of mobile terminal or WEB terminal alarm information. The user corresponding to the node returns alarm information (ie, work order information).
- the contract node 20a obtains the firmware update request, and authenticates the legality of the firmware update request based on the firmware version release record, the firmware version update record, and the update version parameters, as shown in the following Figures 2 to 8 corresponds to the embodiment.
- Step S101 Receive a firmware update request for the first server node sent by the execution node.
- the contract node may receive a firmware update request for the first server node sent by the execution node.
- the execution node in the embodiment of the present application needs to send a firmware update request to the contract node before performing the firmware update on the first server node.
- the firmware update request may at least It includes: the update version parameter of the first server node; in the embodiment of the present application, the firmware update request may also include the operating version parameter of the first server node.
- the new firmware version information currently planned to be used for the firmware update of the first server node may be referred to as updated version information (for example, firmware version V2), and the hash of the new firmware version information
- the value is called the updated version hash value (for example, the hash value H2).
- the hash value of the running version here can also be referred to as the hash value of the old firmware.
- the hash value of the updated version can also be referred to as the hash value of the new firmware.
- the execution node before sending the firmware update request, may refer to the acquired operating version parameters and update version parameters as input information for subsequent generation of the firmware version update record, that is, the execution node may The current running version parameters of the first server node (i.e. firmware version V1, hash value H1) and the updated version parameters planned to be used to update the firmware of the first server node (i.e. firmware version V2, hash value) H2) Call it the input information, and sign the input information with the private key of the execution node, and add the signed first signature information and the public key of the execution node to the update request to obtain the aforementioned firmware update request.
- firmware version V1 firmware version V1
- H2 updated version parameters planned to be used to update the firmware of the first server node
- the contract node after receiving the firmware update request, the contract node can perform signature verification on the first signature information of the execution node through the received public key of the execution node, and when the signature verification is successful Obtain the updated version parameters and running version parameters provided by the execution node.
- the execution node may be the execution node 30a located in the implementation layer 300 in the embodiment corresponding to FIG. 1, and the first server node may be the execution node 30a located in the implementation layer 300 in the embodiment corresponding to FIG.
- the server node 40a, the contract node may be the contract node 20a located in the contract layer 200 in the embodiment corresponding to FIG. 1 above.
- the execution node 30a, the server node 40a, and the contract node 20a in the blockchain may be collectively referred to as nodes in the blockchain network. It should be understood that for each node that joins the blockchain, the blockchain can allocate a corresponding public key and private key pair for it.
- the public key of each node can be learned by other nodes in the blockchain, but the respective private key can be properly stored by the corresponding node separately.
- the private key of the server node can be saved based on the trusted computing environment of the Trusted Execution Environment (TEE), which can ensure that other nodes in the blockchain cannot Learn the private key of the server node.
- TEE Trusted Execution Environment
- a specific storage medium can be used to save the private key of the execution node. It can be seen that by properly storing the private key of each node in the blockchain, the security and reliability of the subsequent contract execution process can be ensured.
- the blockchain is equivalent to giving these execution nodes a special identity, which can effectively improve the forgery of execution nodes by illegal attackers.
- the difficulty of illegally operating the server firmware is equivalent to giving these execution nodes a special identity, which can effectively improve the forgery of execution nodes by illegal attackers. The difficulty of illegally operating the server firmware.
- Step S102 Invoke a smart contract according to the firmware update request, and obtain a firmware version update record and a firmware version release record associated with the first server node from the blockchain based on the smart contract; the firmware version release record Is determined by the publishing node on the blockchain based on a consensus mechanism;
- the contract node may call the smart contract to obtain the blockchain address of the first server node in the blockchain; the blockchain address is the blockchain according to the first server node The public key information of is uniquely determined after hash calculation; further, the contract node may obtain the first block and the first block associated with the first server node from the block chain based on the block chain address The second block; further, the contract node may determine the historical version update behavior information carrying the first version parameter and the second version parameter in the first block as the firmware associated with the first server node Version update record; the second version parameter is the version parameter after the firmware update of the first version parameter; further, the contract node can be associated with the first server node from the second block The release behavior information of the historical version is determined as the firmware version release record.
- each node in the blockchain network (that is, each distributed node) can be used as the blockchain system Individual individuals receive, process, and feedback information.
- these nodes located in the blockchain network both receive and generate information, and the nodes can maintain communication by maintaining a common blockchain.
- nodes in the blockchain network can create new blocks, and will notify the blockchain network in the form of broadcast after the new blocks are created.
- Other nodes for example, other contract nodes in the embodiment corresponding to Figure 1 above
- other nodes will verify this block, and when more than 51% of the nodes in the blockchain network pass the verification, confirm that the node is reached Consensus (for example, contract consensus), at this time, this new block can be added to the blockchain.
- Consensus for example, contract consensus
- the contract node can record every time the execution node checks the firmware in the server node through the second version parameter (for example, the above-mentioned first version) during the process of updating and controlling the firmware of the server node through the smart contract.
- the server node is the version update behavior information for the first version parameter of the server node 40a) in the embodiment corresponding to FIG. 1 to perform firmware update.
- the embodiment of the present application may perform an update operation on one firmware or multiple firmware in the server node, which will not be limited here.
- each time the execution node completes an operation to update the firmware in the server node it can generate a firmware update log information, that is, generate a sub-firmware version update record; among them, a firmware update log information (ie The sub-firmware version update record) may include version update behavior information for firmware update of a certain firmware in the first server node.
- the contract node may further collectively refer to the sub-firmware version update record containing the version update behavior information of each firmware as the firmware version update record of the firmware in the first server node.
- each sub-firmware version update record may be collectively referred to as a firmware version update record of the corresponding firmware in the first server node. It should be understood that every time the update operation of the version information of the corresponding firmware of the first server node is completed, a sub-firmware version update record can be generated, so that a firmware version update record can be obtained.
- the execution node during the block generation time period from the generation of the previous block to the generation of the new block, if the execution node has completed the update operation for only one firmware in the first server node, one Sub-firmware version update record. At this time, the sub-firmware version update record can be used as the firmware version update record in the new block.
- the execution node during this block generation time period, if the execution node has completed the update operation for multiple firmware in the first server node, multiple sub-firmware version update records can be obtained. At this time, the These sub-firmware version update records are collectively referred to as the firmware version update records in the new block.
- the embodiment of the present application takes the firmware version update record obtained after the firmware update of the target firmware in the first server node as an example, to illustrate the relationship between the firmware version update record of the target firmware and the first block connection relation.
- FIG. 3 is a schematic diagram of a block structure of a nested hash chain provided by an embodiment of the present application.
- the nested hash chain shown in FIG. 3 may include at least block N, block N+1, and block N+2 shown in FIG. 3. Among them, N can be a positive integer.
- Each block as shown in FIG. 3 records the firmware update log information after the firmware update of the first server node.
- the embodiment of the present application may collectively refer to each firmware update log information (ie, sub-firmware version update records) Update the record for the firmware version.
- each block as shown in Figure 3 can contain the hash (called Header) of the previous block (ie the previous first block) and the corresponding firmware version update Record, that is, the data in the block in the nested hash chain can have uniqueness and traceability.
- block N can contain the hash value of the previous block of the block N (that is, the hash of block N-1 shown in Figure 3) and the firmware for the first server The firmware version update record obtained after the update operation1.
- block N+1 can contain the hash value of the previous block of the block N+1 (that is, the hash of block N shown in Figure 3) and another firmware for the first server node
- the firmware version update record 2 obtained after the update operation; and so on, the block N+2 can contain the hash value of the previous block of the block N+2 (that is, the block N+ shown in Figure 3). 1) and the firmware version update record 3 obtained after another firmware update operation is performed on the first server node.
- the block N, block N+1, and block N+2 shown in FIG. 3 may be referred to as the first block.
- These first blocks may include update records of sub-firmware version obtained after updating the firmware version information of the target firmware (for example, firmware K) in the first server node.
- block N may contain the sub-firmware version update record of the firmware K
- block N+1 may contain the sub-firmware version update record of the firmware K
- block N+2 may contain the sub-firmware version of the firmware K. Version update record.
- the embodiment of the present application takes a block in the first block (for example, block N+1) as an example to illustrate the firmware version update in the block N+1
- Record 2 may contain multiple sub-firmware version update records, which may specifically be update record 1, update record 2, update record 3, and update record 4 shown in FIG. 3.
- the update record 1 may be the update record of the sub-firmware version of the firmware K found in the block N+1.
- the timestamp in the block header 10 as shown in FIG. 3 can uniquely identify the position of a block in the blockchain.
- the block body 20 as shown in FIG. 3 may contain all historical version update behavior information for updating the firmware of the first server node during the period before block N+1 is generated and after block N is generated. .
- a sub-firmware version update record can be generated (that is, an update record or a firmware update log message can be generated).
- the update records corresponding to all completed firmware update operations during this period can be referred to as the firmware version update record 2 shown in Figure 3. That is, the firmware version update record 2 can contain multiple sub-firmware version update records .
- update record 1, update record 2, update record 3, and update record 4 as shown in FIG. 3 can be organized together in the form of a Merkel tree.
- the construction process of the Merkel tree shown in Fig. 3 is a process of recursively calculating the hash value (that is, recursively calculating the hash value).
- the hash value 1 corresponding to update record 1 can be calculated by the SHA256 hash calculation method; similarly, the hash value 1 corresponding to update record 2 can be calculated by the SHA256 hash calculation method.
- Hash value 2 Further, the hash value 1 and the hash value 2 are connected in series, and the hash transformation is continued, and the hash value 12 shown in FIG. 3 can be obtained.
- the hash value 34 shown in Figure 3 can be obtained, so that the hash value 12 and the hash value 34 can be further combined. Connect them in series to perform hash transformation until the last root is left (that is, the hash value 1234 shown in Figure 3).
- the embodiment of the present application may use the finally obtained hash value of all transaction information as the root of the Merkel tree of block N+1. It can be seen that the scalability of the Merkel tree is very good. No matter how many records are updated, a Merkel tree and a fixed-length Merkel tree root can be generated at the end. It should be understood that the structure of the Merkel tree in the embodiment of the present application can be used to ensure the efficiency of the version search in the subsequent firmware version tracing process.
- the same blockchain network of mixed firmware sources can be used to perform version management control (for example, version release control and version update control) on the firmware in the first server node, that is, the version control Distinguish between server vendors in the process.
- version management control for example, version release control and version update control
- different contract nodes can be used for version update control.
- the firmware version information released by the manufacturer A can be updated through the contract node 20a shown in FIG. 1
- the firmware version information released by the manufacturer B can be updated through the contract node 20b shown in FIG.
- different blockchain networks can also be established to manage the firmware update of the firmware version information issued by different manufacturers. There will be no restrictions on the specific construction form of the blockchain network.
- the embodiment of the present application takes as an example the update operation of a firmware in the first server node (for example, the aforementioned firmware K) as the target firmware.
- the contract node calls the smart contract, it can obtain the first server node.
- a block chain address in the block chain where the server node is located, and the historical update situation and historical release situation of the firmware K are consulted in the block chain record corresponding to the block chain address.
- the first block and the second block associated with the first server node are acquired on the blockchain, so that the first block will carry the history of the first version parameter and the second version parameter of the target firmware
- the version update behavior information serves as a firmware version update record associated with the first server node.
- the contract node can also use the historical version release behavior information associated with the firmware K in the first server node from the second block as a firmware version release record to further execute step S103.
- the legality of the firmware update request currently sent by the execution node can be distinguished, so as to improve the security and reliability of the firmware update.
- firmware version release record is determined by the release node on the blockchain based on the consensus mechanism, that is, the embodiment of this application can determine the release of a certain release node when a consensus is reached between the release nodes.
- the new firmware version release parameters can be recognized by contract nodes, so that when contract nodes reach a contract consensus, the block containing the new firmware version release parameters can be written into the blockchain for storage.
- FIG. 4a and FIG. 4b are schematic diagrams of performing version release control provided by an embodiment of the present application.
- the contract node 1 receives the new firmware version release parameters (ie, the firmware version) of the firmware K broadcasted by the release node 1 (for example, it may be the release node 10a in the embodiment corresponding to Figure 1).
- Parameter 1 you can wait within the time window T shown in Figure 4a, that is, the contract node can wait for the same firmware released by other publishing nodes within the preset time window T in the embodiment corresponding to Figure 1 above.
- Version release parameters ie, the firmware version of the firmware K broadcasted by the release node 1
- Parameter 1 the new firmware version release parameters
- the contract node 1 receives the new firmware version release parameters (ie, the firmware version) of the firmware K broadcasted by the release node 1 (for example, it may be the release node 10a in the embodiment corresponding to Figure 1).
- Parameter 1 you can wait within the time window T shown in Figure 4a, that
- the release node 1 can receive the latest version of the firmware file released by the manufacturer (for example, manufacturer A), and can analyze the file structure of the received latest version of the firmware file, so that the file content can be further determined according to the content of the file.
- the internal version number and calculate the hash value of the internal version number. It should be understood that the internal version number here refers to the latest firmware version information released by the manufacturer A for the firmware K in the first server node.
- the latest firmware version information of the firmware K and the hash value of the latest firmware version information can be called It is the firmware version release parameters of the firmware K, and a firmware release request carrying the firmware version release parameters can be sent to the contract node 1 shown in FIG. 4b, so that the contract node 1 can perform step S5 shown in FIG. 4b.
- the release node 1 in order to ensure the integrity of data transmission in the blockchain, the release node 1 will also pass the firmware version release parameters of the firmware K to the contract node 1 shown in Figure 4b.
- the private key of the publishing node 1 signs the firmware version release parameters (ie, the firmware version release parameter 1 shown in Figure 4a), so that the signed signature result and the public key of the publishing node 1 can be given to the contract node. 1. So that when contract node 1 receives the firmware release request sent by release node 1, it can use the public key of the release node 1 to perform signature verification on the signature result to obtain the firmware version release parameters carried in the firmware release request 1.
- Step S103 Determine the legitimacy of the firmware update request according to the firmware version update record, the firmware version release record, and the update version parameter.
- the contract node may perform rollback detection on the updated version parameter based on the first version parameter in the firmware version update record; if it is detected that the first version parameter is the same as the updated version parameter, It is determined that there is a version rollback, and it is determined that the firmware update request is an illegal update request; the illegal update request is used to indicate that the execution node does not have the right to perform firmware update on the version information of the first server node; if it is detected When the first version parameter is different from the updated version parameter, it is determined that there is no version rollback, and the legality of the firmware update request is determined based on the updated version parameter and the firmware version release record.
- Table 1 is a firmware version update record table of firmware K provided in an embodiment of the present application.
- firmware version update record A is obtained after the execution node performs the firmware update of the firmware K in the first server node for the first time
- firmware version update record B is the second time the execution node performs the firmware update on the first server node.
- Firmware K is obtained after firmware update.
- the second version release behavior information in the historical version release behavior information includes the updated version parameters
- the hash value of the updated version information can be directly compared with the hash value of the latest released firmware version release information. If the hash values of the two are the same, that is, it is determined that the hash values of the firmware version are the same, the contract check can be used to determine that the firmware update request sent by the execution node in step S201 is a legal update request. In the embodiment of the present application, if the hash values of the two are different, it is determined that the contract detection fails, so that the following step S207-step S208 can be further jumped to.
- Step S206 When it is determined that the firmware update request is a legal update request, return to the execution node feedback information for performing firmware update on the first server node; the feedback information is used to instruct the execution node to The firmware version information of the first server node is updated from the operating version information in the operating version parameter to the updated version information in the updated version parameter.
- Step S207 When it is detected that the firmware update request is an illegal update request, confirm that the contract execution has failed, and return the illegal update request to the execution node;
- the contract node after the contract node has performed the above step S206, it may also perform the following steps: receive the confirmation information after the first server node signs the updated version parameters; the confirmation information is used to indicate The execution node has completed the update of the firmware version information of the first server node; the confirmation information is signed and verified by the public key information of the first server node, and when the signature verification is successful, it is determined that the verification is completed.
- the call of the smart contract based on the confirmation information and the firmware update request, the firmware version update record of the first server node is updated, and the updated firmware is updated based on the blockchain address of the first server node
- the version update record is written into the blockchain.
- FIG. 7 is a schematic diagram of constructing a firmware version update record provided by an embodiment of the present application.
- the firmware version update record 4 shown in Fig. 7 is composed of input information and output information.
- the input information may be the running version parameters and the updated version parameters provided by the node A involved in the execution of the smart contract by the contract node.
- the first signature information obtained later is added to the firmware update request and sent to the contract node. Therefore, in the process of invoking the smart contract, the contract node can use the public key of the execution node A to perform signature verification on the first signature information to obtain the aforementioned input parameters (that is, the input information) from the firmware update request. Update version parameters and running version parameters of firmware K.
- the output information may include the new operating version parameters collected and reported by the server node B (ie, the first server node).
- the new operating version parameters may be firmware updates to the operating version parameters using the updated version parameters.
- the new running version information running on the first server node may be the updated version parameter shown in FIG. 7 with the new firmware version being V2 and the new firmware hash value being H2.
- the first server node before sending the confirmation information to the contract node, the first server node can use the currently collected new running version parameters as output information, and sign the output information with the private key of server node B.
- the second signature information is obtained, and the second signature information and the public key of the server node B are added to the output information and sent to the contract node.
- the collection node can also be used to continuously collect the first server node off-chain.
- the collection frequency of the firmware information in the server node may be that the collection of the firmware information of the first server node is started every time the first server node is restarted; in the embodiment of the present application, it may also be started periodically or periodically Collection of the firmware information of the first server node.
- the collection method is not limited to the use of automatic collection and analysis tools (for example, a unified and extensible firmware interface tool, etc.).
- the publishing node can perform a security audit on the security status of any server node located on the blockchain to determine the security status of these server nodes by comparing the off-chain firmware information of these server nodes with the on-chain firmware information.
- the embodiment of the present application may take one of the server nodes (that is, the server node 40a in the embodiment corresponding to FIG. 1 as the first server node) as an example, to illustrate that the publishing node has an effect on the server node 40a. (Ie the first server node) the specific implementation process of security auditing.
- the publishing node may also periodically or periodically read the firmware information currently running in the server node 40a from the server node 40a, and call the currently read firmware information as the chain Download the firmware information.
- the work order information can include but is not limited to: (1) event time (i.e. the time for the security audit of the first server node); (2) business information, such as the person in charge of the machine, the area to which it belongs, and the affiliation Business, corresponding IP, and corresponding public key; (3) The reported firmware version and firmware hash; (4) The machine information recorded on the chain, such as the machine public key, firmware version, and firmware hash; (5) Last update event , Including update time, update performer information, etc.
- event time i.e. the time for the security audit of the first server node
- business information such as the person in charge of the machine, the area to which it belongs, and the affiliation Business, corresponding IP, and corresponding public key
- the reported firmware version and firmware hash (4) The machine information recorded on the chain, such as the machine public key, firmware version, and firmware hash
- Last update event Including update time, update performer information, etc.
- the first terminal may, when receiving the firmware update request for the first server node sent by the execution node, call the smart contract to perform intelligent update management and control on the firmware update request initiated by the execution node, so as to ensure the firmware update Security.
- the firmware update request can carry the update version parameters planned to update the firmware of the first server node.
- the contract node can obtain the firmware version update record and the firmware version update record associated with the first server node from the blockchain.
- FIG. 9 is a schematic structural diagram of a data processing device based on a smart contract provided by an embodiment of the present application.
- the data processing device 1 can be applied to the contract node 20a in the embodiment corresponding to FIG. 1 above.
- the data processing device 1 may include: a request receiving module 10, a contract invoking module 20, and a legal determination module 30.
- the data processing device 1 may also include: a confirmation receiving module 40 and a signature verification module 50 And record update module 60.
- the request receiving module 10 is configured to receive a firmware update request for a first server node sent by an execution node; the firmware update request includes at least: an update version parameter of the first server node;
- the contract invocation module 20 is configured to invoke a smart contract according to the firmware update request, and obtain a firmware version update record and a firmware version release record associated with the first server node from the blockchain based on the smart contract;
- the firmware version release record is determined by the release node on the blockchain based on a consensus mechanism;
- the contract invocation module 20 includes: an address acquisition unit 201, a block acquisition unit 202, an update record determination unit 203, and a release record determination unit 204;
- a block obtaining unit 202 configured to obtain a first block and a second block associated with the first server node from the block chain based on the block chain address;
- the update record determining unit 203 is configured to determine the historical version update behavior information carrying the first version parameter and the second version parameter in the first block as the firmware version update record associated with the first server node ;
- the second version parameter is the version parameter after the firmware update of the first version parameter;
- the release record determining unit 204 is configured to determine the historical version release behavior information associated with the first server node from the second block as a firmware version release record.
- the legality determination module 30 is configured to determine the legality of the firmware update request according to the firmware version update record, the firmware version release record, and the update version parameter.
- the legality determination module 30 includes: a rollback detection unit 301, an illegality determination unit 302, and a legality determination unit 303;
- a rollback detection unit 301 configured to perform rollback detection on the updated version parameter based on the first version parameter in the firmware version update record
- the illegal determination unit 302 is configured to, if it is detected that the first version parameter is the same as the update version parameter, determine that there is a version rollback, and determine that the firmware update request is an illegal update request; the illegal update request is used to indicate The execution node does not have the right to perform firmware update on the version information of the first server node;
- the node obtaining subunit 3033 is configured to detect that the first version release behavior information does not include the updated version parameters, and the second version release behavior information in the historical version release behavior information If the updated version parameter is included, M second server nodes that have used the updated version parameter for firmware update are searched from the blockchain; M is a positive integer greater than 2;
- the third determining subunit 3036 is configured to determine that the firmware update request is an illegal update when it is detected that the version update behavior information of the M second server nodes does not include the operating version parameter. request.
- the alarm information is based on the on-chain update version parameter of the first server acquired from the blockchain and the update collected locally from the first server node by the publishing node
- the latter operating version parameters are obtained after security auditing.
- the first publishing subunit 3031, the first determining subunit 3032, the node obtaining subunit 3033, the behavior obtaining subunit 3034, the second determining subunit 3035, the third determining subunit 3036, the feedback subunit 3037, and the request returning subunit For the specific implementation of the unit 3038 and the illegal identification subunit 3039, reference may be made to the description of step S103 in the embodiment corresponding to FIG. 2 above, which will not be repeated here.
- step S103 For specific implementations of the rollback detection unit 301, the illegal determination unit 302, and the legal determination unit 303, refer to the description of step S103 in the embodiment corresponding to FIG. 2 above, and the details will not be repeated here.
- the confirmation receiving module 40 is configured to receive confirmation information after the first server node signs the updated version parameters; the confirmation information is used to indicate that the execution node has completed the Update of the firmware version information of the first server node;
- the signature verification module 50 is configured to perform signature verification on the confirmation information through the public key information of the first server node, and determine to complete the call to the smart contract when the signature verification is successful;
- the record update module 60 is configured to update the firmware version update record of the first server node based on the confirmation information and the firmware update request, and update the updated version based on the blockchain address of the first server node
- the firmware version update record is written into the blockchain.
- the record update module 60 includes: a first information determination unit 601, a second information determination unit 602, an update behavior determination unit 603, and a record writing unit 604;
- the first information determining unit 601 is configured to use the update version parameter and the running version parameter in the firmware update request as input information for constructing a firmware version update record associated with the first server node;
- the second information determining unit 602 is configured to use the update version parameter carried in the confirmation information as output information for constructing a firmware version update record associated with the first server node;
- the update behavior determining unit 603 is configured to determine the target version update behavior information associated with the first server node based on the input information and the output information, and perform the update behavior information on the first server based on the target version update behavior information. Update the firmware version update record of the node;
- the record writing unit 604 is configured to write the updated firmware version update record into the blockchain based on the blockchain address of the server node.
- the first information determining unit 601, the second information determining unit 602, the update behavior determining unit 603, and the record writing unit 604, please refer to the description of the firmware version update record in the embodiment corresponding to FIG. 2 , I will not go into details here.
- the contract invoking module 20, and the legality determining module 30 please refer to the description of step S101 to step S103 in the embodiment corresponding to FIG. 2, which will not be repeated here.
- the specific implementation of the confirmation receiving module 40, the signature verification module 50, and the record update module 60 can refer to the description of step S201 to step S208 in the embodiment corresponding to FIG. 5, which will not be continued here. Go into details.
- the first terminal may, when receiving the firmware update request for the first server node sent by the execution node, call the smart contract to perform intelligent update management and control on the firmware update request initiated by the execution node, so as to ensure the firmware update Security.
- the firmware update request can carry the update version parameters planned to update the firmware of the first server node.
- the contract node can obtain the firmware version update record and the firmware version update record associated with the first server node from the blockchain.
- Firmware version release record which can perform contract detection on the update version parameters in the firmware update request based on the obtained firmware version update record and firmware version release record, so that the firmware update request that meets the contract detection result can be determined as a legal update request
- a firmware update request that does not meet the contract detection result can be determined as an illegal update request. It can be seen that, for all update operations of the underlying firmware of the first server node, the contract node can effectively distinguish legal and illegal firmware update operations through smart contracts, so as to improve the reliability of firmware update.
- FIG. 10 is a schematic structural diagram of a node device provided in an embodiment of the present application.
- the node device 1000 may be applied to the contract node 20a in the embodiment corresponding to FIG. 1.
- the node device 1000 may include a processor 1001, a network interface 1004, and a memory 1005.
- the node The device 1000 may further include: a user interface 1003 and at least one communication bus 1002.
- the communication bus 1002 is used to implement connection and communication between these components.
- the user interface 1003 may include a display screen (Display) and a keyboard (Keyboard), and the user interface 1003 may also include a standard wired interface and a wireless interface.
- the network interface 1004 may include a standard wired interface and a wireless interface (such as a WI-FI interface) in this embodiment of the application.
- the memory 1005 may be a high-speed RAM memory, or a non-volatile memory (non-volatile memory), such as at least one disk memory.
- the memory 1005 may also be at least one storage device located far away from the foregoing processor 1001 in the embodiment of the present application. As shown in Fig. 10, the memory 1005 as a computer storage medium may include an operating system, a network communication module, a user interface module, and a device control application program.
- the network interface 1004 in the node device 1000 can also be connected with other node devices (such as application servers) in the blockchain, and the user interface 1003 can also include a display (Display) and a keyboard (Keyboard).
- the network interface 1004 can provide network communication functions; the user interface 1003 is mainly used to provide an input interface for the user; and the processor 1001 can be used to call application programs stored in the memory 1005, To achieve:
- the firmware update request includes at least: an update version parameter of the first server node;
- the smart contract is called according to the firmware update request, and the firmware version update record and the firmware version release record associated with the first server node are obtained from the blockchain based on the smart contract; the firmware version release record is the The publishing nodes on the blockchain are determined based on the consensus mechanism;
- the node device 1000 described in the embodiment of the present application can execute the description of the smart contract-based data processing method in the previous corresponding embodiment, and can also execute the smart contract-based data processing method in the previous corresponding embodiment.
- the description of the data processing device 1 will not be repeated here.
- the description of the beneficial effects of using the same method will not be repeated.
- the embodiment of the present application also provides a computer storage medium, and the computer storage medium stores the aforementioned computer program executed by the smart contract-based data processing device 1, and
- the computer program includes program instructions, and when the processor executes the program instructions, it can execute the description of the smart contract-based data processing method in the corresponding embodiment above, so it will not be repeated here.
- the description of the beneficial effects of using the same method will not be repeated.
- the program can be stored in a computer readable storage medium, and the program can be stored in a computer readable storage medium. During execution, it may include the procedures of the above-mentioned method embodiments.
- the storage medium may be a magnetic disk, an optical disc, a read-only memory (Read-Only Memory, ROM), or a random access memory (Random Access Memory, RAM), etc.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Stored Programmes (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Description
Claims (15)
- 一种基于智能合约的数据处理方法,所述方法由作为合约节点的电子设备执行,包括:接收执行节点发送的针对第一服务器节点的固件更新请求;所述固件更新请求中至少包含:所述第一服务器节点的更新版本参数;根据所述固件更新请求调用智能合约,基于所述智能合约从区块链上获取与所述第一服务器节点相关联的固件版本更新记录和固件版本发布记录;所述固件版本发布记录为所述区块链上的发布节点基于共识机制所确定的;根据所述固件版本更新记录、所述固件版本发布记录、所述更新版本参数,确定所述固件更新请求的合法性。
- 根据权利要求1所述的方法,所述调用所述智能合约从所述区块链上获取与所述第一服务器节点相关联的固件版本更新记录和固件版本发布记录,包括:调用所述智能合约以获取所述第一服务器节点在所述区块链中的区块链地址;所述区块链地址为所述区块链根据所述第一服务器节点的公钥信息进行散列计算后所唯一确定的;基于所述区块链地址从所述区块链上获取与所述第一服务器节点相关联的第一区块和第二区块;在所述第一区块中将携带第一版本参数和第二版本参数的历史版本更新行为信息,确定为与所述第一服务器节点相关联的固件版本更新记录;所述第二版本参数为对所述第一版本参数进行固件更新后的版本参数;从所述第二区块中将与所述第一服务器节点相关联的历史版本发布行为信息,确定为固件版本发布记录。
- 根据权利要求2所述的方法,所述根据所述固件版本更新记录、所述固件版本发布记录、所述更新版本参数,确定所述固件更新请求的合法性,包括:基于所述固件版本更新记录中的所述第一版本参数,对所述更新版本参数进行回滚检测;若检测到所述第一版本参数与所述更新版本参数相同,则确定存在版本回滚,确定所述固件更新请求为非法更新请求;所述非法更新请求用于指示所述执行节点不具备对所述第一服务器节点的版本信息进行固件更新的权限;若检测到所述第一版本参数与所述更新版本参数不相同,则确定不存在版本回滚,基于所述更新版本参数以及所述固件版本发布记录,确定所述固件更新请求的合法性。
- 根据权利要求3所述的方法,所述基于所述更新版本参数以及所述固件版本发布记录,确定所述固件更新请求为合法更新请求,包括:在与所述固件版本发布记录相关联的历史版本发布行为信息中获取第一版本发布行为信息;所述第一版本发布行为信息为所述历史版本发布行为信息中具有最大版本发布时间戳的版本发布行为信息;若检测到所述第一版本发布行为信息中包含所述更新版本参数,则确定所述固件更新请求为合法更新请求。
- 根据权利要求4所述的方法,所述固件更新请求中还包含:所述第一服务器节点的运行版本参数;所述方法还包括:若检测到所述第一版本发布行为信息不包含所述更新版本参数,但所述历史版本发布行为信息中的第二版本发布行为信息包含所述更新版本参数,则从所述区块链中查找已采用所述更新版本参数进行固件更新的M个第二服务器节点;M为大于2的正整数;获取所述M个第二服务器节点的版本更新行为信息;在检测到所述M个第二服务器节点的版本更新行为信息中均包含所述运行版本参数时,确定所述固件更新请求为合法更新请求;在检测到所述M个第二服务器节点的版本更新行为信息中存在不包含所述运行版本参数的版本更新行为信息时,确定所述固件更新请求 为非法更新请求。
- 根据权利要求5所述的方法,还包括:在确定所述固件更新请求为合法更新请求时,向所述执行节点返回用于对所述第一服务器节点进行固件更新的反馈信息;所述反馈信息用于指示所述执行节点将所述第一服务器节点的固件版本信息由所述运行版本参数中的运行版本信息更新为所述更新版本参数中的更新版本信息。
- 根据权利要求5所述的方法,还包括:在检测到所述固件更新请求为非法更新请求时,则确认合约执行失败,向所述执行节点退回所述非法更新请求;在接收到所述执行节点发送的针对所述第一服务器节点的下一固件更新请求时,将所述下一固件更新请求标识为所述非法更新请求,所述非法更新请求用于指示所述发布节点在进行安全审计时生成针对所述执行节点的告警信息。
- 根据权利要求7所述的方法,所述告警信息是由所述发布节点根据从所述区块链上所获取到的所述第一服务器的链上更新版本参数和从所述第一服务器节点的本地所采集到的更新后的运行版本参数进行安全审计后所得到的。
- 根据权利要求1所述的方法,还包括:接收所述第一服务器节点针对所述更新版本参数进行签名后的确认信息;所述确认信息用于指示所述执行节点已完成对所述第一服务器节点的固件版本信息的更新;通过所述第一服务器节点的公钥信息对所述确认信息进行签名验证,并在签名验证成功时确定完成对所述智能合约的调用;基于所述确认信息和所述固件更新请求,对所述第一服务器节点的固件版本更新记录进行更新,基于所述第一服务器节点的区块链地址将更新后的固件版本更新记录写入所述区块链。
- 根据权利要求9所述的方法,所述基于所述确认信息和所述固 件更新请求对所述第一服务器节点的固件版本更新记录进行更新,基于所述第一服务器节点的区块链地址将更新后的固件版本更新记录写入所述区块链,包括:将所述固件更新请求中的更新版本参数、运行版本参数作为用于构建与所述第一服务器节点相关联的固件版本更新记录的输入信息;将所述确认信息中所携带的所述更新版本参数作为用于构建与所述第一服务器节点相关联的固件版本更新记录的输出信息;基于所述输入信息和所述输出信息,确定与所述第一服务器节点相关联的目标版本更新行为信息,基于所述目标版本更新行为信息对所述第一服务器节点的固件版本更新记录进行更新;基于所述服务器节点的区块链地址将更新后的固件版本更新记录写入所述区块链。
- 一种基于智能合约的数据处理装置,所述装置应用于合约节点,包括:请求接收模块,用于接收执行节点发送的针对第一服务器节点的固件更新请求;所述固件更新请求中至少包含:所述第一服务器节点的更新版本参数;合约调用模块,用于根据所述固件更新请求调用智能合约,基于所述智能合约从区块链上获取与所述第一服务器节点相关联的固件版本更新记录和固件版本发布记录;所述固件版本发布记录为所述区块链上的发布节点基于共识机制所确定的;合法确定模块,用于根据所述固件版本更新记录、所述固件版本发布记录、所述更新版本参数,确定所述固件更新请求的合法性。
- 根据权利要求11所述的装置,所述合约调用模块包括:地址获取单元,用于调用所述智能合约以获取所述第一服务器节点在所述区块链中的区块链地址;所述区块链地址为所述区块链根据所述第一服务器节点的公钥信息进行散列计算后所唯一确定的;区块获取单元,用于基于所述区块链地址从所述区块链上获取与所 述第一服务器节点相关联的第一区块和第二区块;更新记录确定单元,用于在所述第一区块中将携带第一版本参数和第二版本参数的历史版本更新行为信息,确定为与所述第一服务器节点相关联的固件版本更新记录;所述第二版本参数为对所述第一版本参数进行固件更新后的版本参数;发布记录确定单元,用于从所述第二区块中将与所述第一服务器节点相关联的历史版本发布行为信息,确定为固件版本发布记录。
- 根据权利要求12所述的装置,所述合法确定模块包括:回滚检测单元,用于基于所述固件版本更新记录中的所述第一版本参数,对所述更新版本参数进行回滚检测;非法确定单元,用于若检测到所述第一版本参数与所述更新版本参数相同,则确定存在版本回滚,确定所述固件更新请求为非法更新请求;所述非法更新请求用于指示所述执行节点不具备对所述第一服务器节点的版本信息进行固件更新的权限;合法确定单元,用于若检测到所述第一版本参数与所述更新版本参数不相同,则确定不存在版本回滚,基于所述更新版本参数以及所述固件版本发布记录,确定所述固件更新请求的合法性。
- 一种节点设备,包括:处理器以及存储器;所述处理器与所述存储器相连,其中,所述存储器用于存储程序代码,所述处理器用于调用所述程序代码,以执行如权利要求1-10中的任一项所述的方法。
- 一种计算机存储介质,所述计算机存储介质存储有计算机程序,所述计算机程序包括程序指令,当处理器执行所述程序指令时执行如权利要求1-10中的任一项所述的方法。
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2021515047A JP7199775B2 (ja) | 2019-08-29 | 2020-07-13 | スマートコントラクトに基づくデータ処理方法、データ処理装置、ノード機器、及びコンピュータプログラム |
KR1020217010913A KR102577139B1 (ko) | 2019-08-29 | 2020-07-13 | 스마트 계약 기반 데이터 처리 방법, 기기 및 저장 매체 |
EP20829525.3A EP4024812B1 (en) | 2019-08-29 | 2020-07-13 | Smart contract-based data processing method, and device and storage medium |
US17/157,965 US11733991B2 (en) | 2019-08-29 | 2021-01-25 | Data processing method based on intelligent contract, device, and storage medium |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910808351.8A CN110535938B (zh) | 2019-08-29 | 2019-08-29 | 一种基于智能合约的数据处理方法、设备及存储介质 |
CN201910808351.8 | 2019-08-29 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US17/157,965 Continuation US11733991B2 (en) | 2019-08-29 | 2021-01-25 | Data processing method based on intelligent contract, device, and storage medium |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2021036545A1 true WO2021036545A1 (zh) | 2021-03-04 |
Family
ID=68665284
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2020/101558 WO2021036545A1 (zh) | 2019-08-29 | 2020-07-13 | 一种基于智能合约的数据处理方法、设备及存储介质 |
Country Status (6)
Country | Link |
---|---|
US (1) | US11733991B2 (zh) |
EP (1) | EP4024812B1 (zh) |
JP (1) | JP7199775B2 (zh) |
KR (1) | KR102577139B1 (zh) |
CN (1) | CN110535938B (zh) |
WO (1) | WO2021036545A1 (zh) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114520774A (zh) * | 2021-12-28 | 2022-05-20 | 武汉虹旭信息技术有限责任公司 | 基于智能合约的深度报文检测方法及装置 |
WO2022192696A1 (en) * | 2021-03-12 | 2022-09-15 | Landis+Gyr Innovations, Inc. | Distributed ledgers on network gateways |
WO2023119398A1 (ja) * | 2021-12-21 | 2023-06-29 | 株式会社東芝 | ブロックチェーンシステム、ブロックチェーンシステム更新方法及びプログラム |
Families Citing this family (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11347858B2 (en) * | 2019-07-22 | 2022-05-31 | Dell Products L.P. | System and method to inhibit firmware downgrade |
CN110535938B (zh) | 2019-08-29 | 2021-07-27 | 腾讯科技(深圳)有限公司 | 一种基于智能合约的数据处理方法、设备及存储介质 |
CN111182527B (zh) * | 2019-12-27 | 2022-07-26 | 深圳市云伽智能技术有限公司 | Ota固件升级方法、装置、终端设备及其存储介质 |
CN111447092B (zh) * | 2020-03-26 | 2022-11-01 | 杭州复杂美科技有限公司 | 版本监测方法、设备和存储介质 |
CN113495750B (zh) * | 2020-04-01 | 2023-02-10 | 中移物联网有限公司 | 一种设备的升级检测方法、装置及服务器 |
CN111506327B (zh) * | 2020-04-15 | 2023-04-21 | 深圳市迅雷网络技术有限公司 | 区块链节点热升级方法及相关设备 |
CN111541788B (zh) * | 2020-07-08 | 2020-10-16 | 支付宝(杭州)信息技术有限公司 | 区块链一体机的哈希更新方法及装置 |
CN111541553B (zh) | 2020-07-08 | 2021-08-24 | 支付宝(杭州)信息技术有限公司 | 区块链一体机的可信启动方法及装置 |
CN112148333B (zh) * | 2020-10-10 | 2023-11-03 | 上海聪链信息科技有限公司 | 区块链服务器固件更新系统 |
CN112162768B (zh) * | 2020-10-14 | 2022-09-30 | 支付宝(杭州)信息技术有限公司 | 一种区块链升级方法和系统 |
CN112162770B (zh) * | 2020-10-20 | 2023-11-10 | 深圳技术大学 | 基于区块链实现完整性验证的固件版本升级方法及装置 |
CN112347456B (zh) * | 2020-10-28 | 2023-09-01 | 达闼机器人股份有限公司 | 程序验证方法和装置、平台和用户终端及在线服务系统 |
US20220200787A1 (en) * | 2020-12-22 | 2022-06-23 | ProtectedBy.Al, Inc. | System and method for securing computer code using dynamically generated digital signatures |
CN112699112B (zh) * | 2020-12-31 | 2024-02-06 | 东莞盟大集团有限公司 | 一种基于区块链技术的数据挖掘流程分享方法 |
US11662993B2 (en) * | 2021-05-18 | 2023-05-30 | Kyndryl, Inc. | Autonomous management of temporal updates and rollbacks |
CN113722548A (zh) * | 2021-08-30 | 2021-11-30 | 北京天空卫士网络安全技术有限公司 | 一种业务系统中引用关系的处理方法和装置 |
CN115098518B (zh) * | 2022-06-08 | 2024-04-09 | 西安工业大学 | 一种四层智能合约的链上升级方法 |
CN115174385B (zh) * | 2022-06-15 | 2024-04-02 | 桂林电子科技大学 | 一种基于区块链的工业物联网设备固件软件更新方法 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130055233A1 (en) * | 2011-08-25 | 2013-02-28 | Salesforce.Com, Inc. | Streamlined methodology for resolving software integration conflicts |
CN106648669A (zh) * | 2016-12-26 | 2017-05-10 | 广东芬尼克兹节能设备有限公司 | 产品设备远程固件升级方法及系统 |
CN107329794A (zh) * | 2017-07-24 | 2017-11-07 | 上海斐讯数据通信技术有限公司 | 一种发布固件、升级固件的方法及系统 |
CN109889589A (zh) * | 2019-02-18 | 2019-06-14 | 闪联信息技术工程中心有限公司 | 一种基于区块链实现嵌入式硬件ota升级系统及方法 |
CN110535938A (zh) * | 2019-08-29 | 2019-12-03 | 腾讯科技(深圳)有限公司 | 一种基于智能合约的数据处理方法、设备及存储介质 |
Family Cites Families (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2013125405A (ja) * | 2011-12-14 | 2013-06-24 | Seiko Epson Corp | ファームウェア書換方法およびファームウェア、ならびに電子機器 |
CN103544030A (zh) * | 2013-07-04 | 2014-01-29 | Tcl集团股份有限公司 | 软件升级方法、软件升级系统及智能终端 |
JP2016126693A (ja) * | 2015-01-08 | 2016-07-11 | 富士通株式会社 | 制御手順方法、制御手順プログラム及び制御手順装置 |
JP2016161986A (ja) * | 2015-02-26 | 2016-09-05 | キヤノン株式会社 | システム、バージョンアップ方法およびプログラム、並びに、情報処理装置 |
US10033534B2 (en) * | 2015-12-01 | 2018-07-24 | Intel Corporation | Methods and apparatus to provide for efficient and secure software updates |
KR101796690B1 (ko) * | 2016-06-28 | 2017-11-10 | 상명대학교 천안산학협력단 | 블록체인 기반의 펌웨어 무결성 검증 시스템 및 그 방법 |
US10185550B2 (en) * | 2016-09-28 | 2019-01-22 | Mcafee, Inc. | Device-driven auto-recovery using multiple recovery sources |
CN106972961A (zh) * | 2017-03-21 | 2017-07-21 | 上海动联信息技术股份有限公司 | 一种基于蓝牙的安全设备固件升级方法 |
US10657261B2 (en) * | 2017-11-30 | 2020-05-19 | Mocana Corporation | System and method for recording device lifecycle transactions as versioned blocks in a blockchain network using a transaction connector and broker service |
EP4131033A1 (en) * | 2018-01-25 | 2023-02-08 | Fortress Cyber Security, LLC | Secure storage of data and hashes via a distributed ledger system |
CN108270874B (zh) * | 2018-02-05 | 2021-04-23 | 武汉斗鱼网络科技有限公司 | 应用程序的更新方法及装置 |
CN108830720B (zh) | 2018-06-21 | 2021-04-30 | 北京京东尚科信息技术有限公司 | 智能合约运行方法、装置、系统和计算机可读存储介质 |
US20200058007A1 (en) * | 2018-08-15 | 2020-02-20 | NEC Laboratories Europe GmbH | Data exchange platform using blockchain |
CN109493216B (zh) * | 2018-09-30 | 2021-02-09 | 北京小米移动软件有限公司 | 模型训练方法、装置、系统及存储介质 |
DE102018129354A1 (de) * | 2018-11-21 | 2020-05-28 | Phoenix Contact Gmbh & Co. Kg | Verfahren zum Bearbeiten von Anwendungsprogrammen auf einem verteilten Automatisierungssystem |
CN110096294B (zh) * | 2019-05-07 | 2022-08-16 | 柏科智能(厦门)科技有限公司 | 一种可任意断点无线升级mcu应用程序的方法 |
-
2019
- 2019-08-29 CN CN201910808351.8A patent/CN110535938B/zh active Active
-
2020
- 2020-07-13 WO PCT/CN2020/101558 patent/WO2021036545A1/zh unknown
- 2020-07-13 JP JP2021515047A patent/JP7199775B2/ja active Active
- 2020-07-13 KR KR1020217010913A patent/KR102577139B1/ko active IP Right Grant
- 2020-07-13 EP EP20829525.3A patent/EP4024812B1/en active Active
-
2021
- 2021-01-25 US US17/157,965 patent/US11733991B2/en active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130055233A1 (en) * | 2011-08-25 | 2013-02-28 | Salesforce.Com, Inc. | Streamlined methodology for resolving software integration conflicts |
CN106648669A (zh) * | 2016-12-26 | 2017-05-10 | 广东芬尼克兹节能设备有限公司 | 产品设备远程固件升级方法及系统 |
CN107329794A (zh) * | 2017-07-24 | 2017-11-07 | 上海斐讯数据通信技术有限公司 | 一种发布固件、升级固件的方法及系统 |
CN109889589A (zh) * | 2019-02-18 | 2019-06-14 | 闪联信息技术工程中心有限公司 | 一种基于区块链实现嵌入式硬件ota升级系统及方法 |
CN110535938A (zh) * | 2019-08-29 | 2019-12-03 | 腾讯科技(深圳)有限公司 | 一种基于智能合约的数据处理方法、设备及存储介质 |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2022192696A1 (en) * | 2021-03-12 | 2022-09-15 | Landis+Gyr Innovations, Inc. | Distributed ledgers on network gateways |
US11775562B2 (en) | 2021-03-12 | 2023-10-03 | Landis+Gyr Technology, Inc. | Distributed ledgers on network gateways |
WO2023119398A1 (ja) * | 2021-12-21 | 2023-06-29 | 株式会社東芝 | ブロックチェーンシステム、ブロックチェーンシステム更新方法及びプログラム |
CN114520774A (zh) * | 2021-12-28 | 2022-05-20 | 武汉虹旭信息技术有限责任公司 | 基于智能合约的深度报文检测方法及装置 |
CN114520774B (zh) * | 2021-12-28 | 2024-02-23 | 武汉虹旭信息技术有限责任公司 | 基于智能合约的深度报文检测方法及装置 |
Also Published As
Publication number | Publication date |
---|---|
EP4024812A4 (en) | 2022-10-19 |
EP4024812A1 (en) | 2022-07-06 |
CN110535938B (zh) | 2021-07-27 |
JP2022502738A (ja) | 2022-01-11 |
CN110535938A (zh) | 2019-12-03 |
KR20210057149A (ko) | 2021-05-20 |
KR102577139B1 (ko) | 2023-09-08 |
US11733991B2 (en) | 2023-08-22 |
EP4024812B1 (en) | 2024-06-26 |
JP7199775B2 (ja) | 2023-01-06 |
US20210149663A1 (en) | 2021-05-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2021036545A1 (zh) | 一种基于智能合约的数据处理方法、设备及存储介质 | |
WO2021073452A1 (zh) | 基于区块链网络的数据处理方法、装置、电子设备及存储介质 | |
US10754989B2 (en) | Runtime self-correction for blockchain ledgers | |
US11831772B2 (en) | Blockchain multi-party shared-governance-based system for maintaining domain name information | |
US11387979B2 (en) | Partially-ordered blockchain | |
US9286369B2 (en) | Data replication across enterprise boundaries | |
US11940971B2 (en) | Blockchain implementing reliability database | |
US20170236123A1 (en) | Decentralized processing of global naming systems | |
CN111523890B (zh) | 基于区块链的数据处理方法、装置、存储介质及设备 | |
US20210266163A1 (en) | Blockchain hybrid consensus-based system for maintaining domain name information | |
US20200128044A1 (en) | System and method for detecting replay attack | |
US11669532B2 (en) | Blockchain implementing reliability database | |
EP3709568A1 (en) | Deleting user data from a blockchain | |
CN110597918A (zh) | 一种账户管理方法、装置及计算机可读存储介质 | |
CN110808839B (zh) | 一种区块链异常数据的处理方法、装置、设备和介质 | |
US11070563B2 (en) | Trace-based transaction validation and commitment | |
CN112527912A (zh) | 基于区块链网络的数据处理方法、装置及计算机设备 | |
CN111506661B (zh) | 一种内容访问管理方法、装置和存储介质 | |
CN113011960A (zh) | 基于区块链的数据访问方法、装置、介质及电子设备 | |
CN113194159B (zh) | Dns权威数据管理方法及系统 | |
Kim et al. | A new cost-saving and efficient method for patch management using blockchain | |
US20240214228A1 (en) | Blockchain based public key infrastructure | |
CN112822279B (zh) | 基于智能感知与可信存储的监测方法及装置 | |
CN110569251B (zh) | 一种数据处理方法、相关设备及计算机可读存储介质 | |
CN117171812A (zh) | 基于区块链的多源可信数据生产方法、区块链节点及系统 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
ENP | Entry into the national phase |
Ref document number: 2021515047 Country of ref document: JP Kind code of ref document: A |
|
ENP | Entry into the national phase |
Ref document number: 20217010913 Country of ref document: KR Kind code of ref document: A |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 20829525 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
ENP | Entry into the national phase |
Ref document number: 2020829525 Country of ref document: EP Effective date: 20220329 |