A security audit method for multi-chain collaboration scenarios

Abstract

The present invention discloses a security audit method for a multi-chain collaboration scenario, and the steps include: 1) performing security detection on the operating environment of the set nodes in each single-chain system to be connected to the multi-chain collaboration scenario, and performing step 2) after the detection is passed; wherein, the set nodes include nodes for block information synchronization or consensus participation, and nodes for inter-chain transaction processing or verification; each single-chain system corresponds to a blockchain system; 2) auditing each of the single-chain systems according to the audit method of the blockchain system, and adding the single-chain system after the audit is passed to the multi-chain collaboration scenario; 3) auditing the blocks, transactions and asset security of the multi-chain collaboration scenario; and auditing the consistency and availability of cross-chain transaction activities in the multi-chain collaboration scenario. The present invention has full audit coverage, is suitable for audits in multi-chain scenarios, and greatly improves the security of multi-chain collaborative transactions.

Description

Technical Field

[0001] The present invention belongs to the field of blockchain information security technology, and specifically, is an information security audit method for various transaction activities in a collaborative scenario of multiple blockchain systems. Background Art

[0002] Recently, security attacks on multi-chain collaboration scenarios have occurred frequently, causing serious damage and economic losses. In view of this, it is necessary to conduct systematic security audits before the applications, protocols and facilities of multi-chain collaboration scenarios are launched, fully assess possible security issues and make corresponding repairs.

[0003] For the security audit of blockchain systems, the current research on the attack surface of smart contracts and underlying systems is extensive, and academia and industry have summarized many types of security issues. For example, for the coding and operation security of smart contracts, there are possible types of problems and security audit points such as reentrancy, delegate call, visibility, price prediction, unchecked conditions or return values; for the security of blockchain underlying systems, there are many security analysis issues summarized from the network, remote call (RPC), consensus and transaction mechanisms such as Sybil attack, denial of service attack, long-range attack, and scalability attack. Despite this, there is still a lack of a dedicated multi-chain collaborative security audit solution. (1) Existing security analysis methods for blockchain systems are not fully applicable to the audit of multi-chain collaborative scenarios. For example, the arbitrary execution of protocol functions involved in the PolyNetwork security incident is different from the generation and inspection method of similar problems in smart contracts. The cross-chain mechanism problem involved in the Wormhole incident is not a common focus of the underlying system audit. The Ronin incident involves the attack on the cross-chain verification node, which is difficult to be discovered in advance through the security audit methods of smart contracts and underlying systems. (2) The security audit methods used for distributed systems are also difficult to use in multi-chain collaboration scenarios. The nodes or subsystems in a distributed system are usually consistent or similar in implementation, while the blockchain systems in a multi-chain collaboration scenario are usually heterogeneous. This means that even if the differences in system implementation are excluded, the focus of the two on security audits is not consistent. For example, compared with a distributed system, a single chain in a multi-chain collaboration scenario can often run independently, and therefore pays more attention to consistency, while a distributed system pays attention to consistency, availability, and partition tolerance at the same time. Summary of the invention

[0004] In order to overcome the above-mentioned deficiencies of existing security audit methods, the present invention provides a security audit method for a multi-chain collaboration scenario based on the transaction collaboration mechanism and characteristics in a multi-chain scenario.

[0005] The technical solution adopted by the present invention is as follows:

[0006] (1) Before conducting a security audit for a multi-chain scenario, first conduct a thorough host and network security analysis and testing of the operating environment of the nodes used for block information synchronization or consensus participation and the nodes used for inter-chain transaction processing or verification, and enhance the security of related software, hardware and network access.

[0007] (2) Furthermore, before conducting a security audit for a multi-chain scenario, the single-chain system is analyzed according to the traditional audit method of the blockchain system to enhance its security when connected to a multi-chain collaboration scenario.

[0008] (3) Further, for multi-chain collaboration scenarios, conduct block, transaction and asset security audits from the perspective of collaborative nodes:

[0009] i. Carry out a check on the correctness of block information to verify whether the block information synchronized by the collaborative nodes in the multi-chain collaboration scenario is the same as the block information formed by the consensus mechanism of each single-chain system connected to the multi-chain collaboration scenario; when the historical block information of the collaboration is the same, the audit is passed; otherwise, the multi-chain collaboration should be suspended and repaired.

[0010] ii. Conduct a block synchronization timeliness check to verify whether the collaborative nodes synchronize block information in a timely manner and the impact caused when this happens; when all the collaborative historical blocks are checked to have no timeouts, the audit is passed; otherwise, the impact on multi-chain collaboration should be judged. When it affects the correctness of transactions, the multi-chain collaboration should be suspended and repaired.

[0011] iii. Conduct transaction legitimacy checks to verify whether the transactions received (or sent) by the nodes participating in cross-chain transactions have abnormal transaction parameters or abnormal results on the initiating chain and the receiving chain; when historical transactions or test transactions pass the transaction legitimacy check, or are found to be illegal and not executed, the audit is passed; otherwise, multi-chain collaboration should be suspended and repaired. Transaction parameter abnormalities are related to the transaction parameter design and implementation of each participating blockchain system. If they do not comply with the design documents or conflict with the implementation, the parameters are considered abnormal; the result abnormalities are related to the transaction integrity check and the transaction design; for example, if c assets are sent from chain A to chain B, if the amount of assets received on chain B is not c, it is considered that the integrity check has not passed and the result is abnormal.

[0012] iv. Conduct transaction validity checks to verify whether the legitimate transactions received (or sent) by the nodes participating in the cross-chain transaction have been executed on the initiating chain and the receiving chain and successfully written into the corresponding block ledger; when the historical transactions or test transactions pass the transaction validity check, or are found to be invalid and not executed, the audit is passed; otherwise, its impact on multi-chain collaboration should be judged. When it affects the correctness of the transaction, the multi-chain collaboration should be suspended and repaired.

[0013] v. Carry out cross-chain asset locking inspections. Based on the time, quantity, locking and unlocking permissions, check whether the time, asset quantity and permission setting conditions for cross-chain asset locking and unlocking will lead to unreasonable situations such as permanent locking of some assets and malicious misappropriation, and whether the privacy of the relevant locked assets is consistent with the cross-chain mechanism design; when both the cross-chain code and historical transactions pass the cross-chain asset locking inspection, the audit is passed; otherwise, multi-chain collaboration should be suspended and repaired.

[0014] vi. Carry out security and reliability inspections of cross-chain assets, apply traditional contract auditing methods and vulnerability detection methods based on cross-chain protocol implementation languages, and detect the security of the code implementation of the asset custody model; detect the block records and event logs of cross-chain transactions by writing integrity check codes, and check the accuracy of the code implementation of cross-chain assets in asset quantity exchange and identity verification; evaluate the asset custody model of the protocol, check the authority allocation of asset custody, the corresponding private key storage location and the number of verification nodes and the degree of decentralization, and audit the reliability of custody. When the cross-chain code and historical transactions pass the cross-chain asset security and reliability inspection, the audit is passed; otherwise, the multi-chain collaboration should be suspended and repaired; when the cross-chain code and historical transactions pass the cross-chain asset security and reliability inspection, the audit is passed; otherwise, the multi-chain collaboration should be suspended and repaired.

[0015] (4) Furthermore, for multi-chain collaboration scenarios, conduct consistency and availability audits of cross-chain transaction activities:

[0016] i. Carry out consistency checks on cross-chain transactions to verify the atomicity and uniqueness of the transaction execution process, that is, whether it is executed as a whole; verify the rollback mechanism when the sub-transaction fails, that is, whether the block ledger can be restored to the state before the transaction was initiated in the event of failure; verify whether the relevant transactions in the initiating chain and the receiving chain are successfully written into the block ledger and meet the final consistency conditions on the multi-chain; when the consistency check of the cross-chain transaction passes, the audit is passed; otherwise, the multi-chain collaboration should be suspended and repaired.

[0017] ii. Conduct availability checks on cross-chain transactions to verify the appropriate isolation of the multi-chain collaboration mechanism, that is, when one chain cannot operate normally due to attacks, etc., cross-chain transactions between other chains are still available; verify whether there is a processing mechanism for malicious nodes, and evaluate the availability of cross-chain services when malicious nodes exist; if all cross-chain transaction availability checks pass, the audit is passed; otherwise, multi-chain collaboration should be suspended and repaired.

[0018] iii. Carry out compatibility checks on cross-chain call codes, including checking whether the call function exists and is available, whether the exception handling mechanism exists and is correct, whether the function execution logic is consistent with the cross-chain mechanism design, etc., to discover the impact of compatibility issues on consistency and availability; if the compatibility check of the cross-chain call code passes, the audit is passed;

[0019] Otherwise, multi-chain collaboration should be suspended and repaired.

[0020] The beneficial effects of the present invention are:

[0021] The present invention provides an information security audit method applicable to the multi-chain scenario, targeting the transaction collaboration mechanism and characteristics in the multi-chain scenario. In contrast, the existing traditional audit focus on smart contracts and blockchain underlying systems cannot fully cover the security issues in the multi-chain scenario. For example, the issues involved in the PolyNetwork, Wormhole and Ronin incidents are difficult to discover in advance through traditional audits; other security audit methods for distributed systems are also difficult to use in multi-chain collaboration scenarios, and the two have different focuses on security audits. The introduction of the present invention will help fill this gap and greatly improve the transaction security of multi-chain collaboration scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Figure 1 It is an implementation flow chart of the present invention.

[0023] Figure 2 It is an implementation example of block, transaction, and asset auditing from the perspective of collaborative nodes.

[0024] Figure 3 It is an implementation example of consistency and availability auditing of cross-chain transaction activities. DETAILED DESCRIPTION

[0025] The present invention is further described in detail below in conjunction with the accompanying drawings. The examples given are only used to explain the present invention but not to limit the scope of the present invention.

[0026] Embodiments of the present invention include but are not limited to the following examples.

[0027] This embodiment provides a security audit method for multi-chain collaboration scenarios, such as Figure 1 As shown. Before conducting a security audit for a multi-chain scenario, fully analyze and test the operating environment of the participating nodes and fully audit the security of the single-chain system. On this basis, conduct a block, transaction, and asset security audit from the perspective of collaborative nodes, and conduct a consistency and availability audit of cross-chain transaction activities. The details are as follows:

[0028] (1) Fully analyze and test the operating environment of nodes participating in multi-chain collaboration (including nodes that synchronize block information, participate in consensus mechanisms, process multi-chain transactions, participate in inter-chain verification, etc.). Based on the experience of handling security incidents, for the inspection of network access environment, we can focus on checking the possible events that cause network access abnormalities, such as BGP hijacking, DNS pollution, DDoS attacks, and witch attacks, based on the facts of manual inspection and log records; for the node's own hardware and software environment, we can combine the on-chain data and local logs to determine whether the block information is likely to be damaged or tampered with, whether the host authority is likely to be maliciously controlled, and whether the private key or signature is safe, so as to fully evaluate the security of the node;

[0029] (2) Audit the security of each blockchain system involved in multi-chain collaboration. Based on the traditional audit methods of blockchain systems, check specific security issues on blockchains such as eclipse attacks, long-range attacks, and scalability attacks from the perspectives of network, remote calls, consensus, and transactions; conduct business logic audits of corresponding parameters, boundary conditions, and state correctness for the specific implementation of each blockchain system; in addition, for non-blockchain-specific security issues, based on the programming implementation language of each system, check common coding implementation defects through code detection tool scanning and manual confirmation methods, and discover security issues such as conditional competition, information leakage, and pointer reference.

[0030] (3) For multi-chain collaboration scenarios, conduct block, transaction and asset security audits from the perspective of collaborative nodes:

[0031] i. Check the correctness of block information. Count the block data on each blockchain system that is synchronously recorded by the local statistics node, generate the corresponding hash value, and compare it with the block data hash value on the browser of each blockchain system, or read by remote call, or in a separately built verification environment to see if they are the same;

[0032] ii. Conduct block synchronization timeliness check. Count the timestamp of each block data synchronized locally by the node, and compare it with the timestamp of the corresponding synchronized block on the browser of each blockchain system or read by remote call to check whether the synchronization time difference is within the set threshold;

[0033] iii. Conduct transaction legitimacy checks. Take the transactions received by the node on a certain chain as an example (similar implementation methods can also be adopted for the transactions sent), and check whether the transactions received by the node meet the design specifications of the receiving chain and the sending chain by comparing the system design documents and implementation codes; check whether the transactions meet the design specifications of the protocol by comparing the cross-chain protocol and various types of transactions generated under the guidance of the protocol; compare the transactions and event logs initiated on the chain, check whether the transactions are likely to be tampered with from the sending chain to the receiving chain, and check whether the semantics of the transactions on the sending chain and the receiving chain are consistent to determine the legitimacy of the transaction.

[0034] iv. Conduct transaction validity check. Taking the transaction received by the node on a certain chain as an example (similar implementation methods can also be adopted for the sent transactions), it is preset that after network congestion timeout, system abnormality and recovery, the rationality of the multi-chain collaborative disposal mechanism is audited, that is, whether the execution is completed on the initiating chain and the receiving chain and successfully written into the corresponding block ledger, or rolled back on the initiating chain and the receiving chain to completely restore the state before the transaction.

[0035] v. Conduct cross-chain asset lock checks. Check the conditions for asset lock and unlock against the cross-chain protocol design documents and implementation codes to see if there are boundary conditions, or whether the time, asset quantity, and permission setting conditions for cross-chain asset lock and unlock may result in the inability to unlock across chains, or abnormal unlock time, or abnormal unlock asset quantity, etc.; check whether assets can be tracked across chains, and determine whether they are consistent with the traceability privacy designed by the protocol.

[0036] vi. Conduct security and reliability checks on cross-chain assets. For smart contracts and cross-chain protocol codes involved in asset activities, apply corresponding traditional contract audit methods and vulnerability detection methods based on protocol implementation languages, and on this basis, check whether the implementation codes for cross-chain asset exchange and proof are logically accurate in ensuring exchange integrity and proof of immutability, and audit the security of related codes; evaluate the asset custody model of the protocol, check the authority allocation of asset custody, the corresponding private key storage location and the number of verification nodes, and the degree of dispersion of actual controllers, and audit the reliability of custody.

[0037] (4) Conduct consistency and availability audits of cross-chain transaction activities for multi-chain collaboration scenarios:

[0038] i. Carry out consistency checks on cross-chain transactions. Check whether all sub-transactions or function calls of cross-chain transactions are submitted for execution in the same block on a single chain, or whether there is a synchronization mechanism to ensure the uniqueness of transactions when executing across blocks; by setting specific conditions, try to make the sub-transactions of cross-chain transactions fail one by one, and verify whether the rollback mechanism of cross-chain transaction execution failure can ensure that the block ledger is restored to the state before the transaction was initiated; when the cross-chain transaction is finally submitted, verify whether the relevant transactions are successfully written into the block ledger on both the initiating blockchain and the receiving blockchain involved in the cross-chain transaction, check the final execution semantics on each chain after the transaction is written, and determine whether the consistency conditions are met.

[0039] ii. Conduct availability checks on cross-chain transactions. Build a corresponding test environment for actual multi-chain collaboration scenarios; for the appropriate isolation that should be ensured in the multi-chain collaboration mechanism, shut down one or more blockchain systems in the test environment, check whether transaction activities that do not involve closed chains are still executed normally, and whether transaction activities involving closed chains have reasonable timeout waiting or execution failure fallback mechanisms; for the processing of malicious nodes, deploy relevant nodes in the test environment, try to launch attacks on one or more blockchain systems from the network, remote call, consensus and transaction functions, and check the relevant processing mechanisms of cross-chain services and under what circumstances cross-chain transaction services are still provided.

[0040] iii. Carry out compatibility check of cross-chain calling code. Obtain functions that need to call or be called by the other blockchain from the design documents of the multi-chain collaboration scenario. The design documents of each blockchain system and cross-chain mechanism of the multi-chain collaboration scenario list the functions that may need to call or be called by the other chain in the multi-chain collaboration scenario. Check whether these functions exist and are available in each single-chain system of the multi-chain collaboration scenario, whether the calling and execution semantics of the relevant functions are consistent with the cross-chain mechanism design (compare the mechanism described in the document and the implemented code to see whether the two are semantically consistent), and whether the on-chain exception handling mechanism can correctly handle the calling error when the relevant function does not exist (jump to the exception handling function and observe the execution semantics of the exception handling function for judgment).

[0041] Although the specific embodiments of the present invention are disclosed for the purpose of illustration, the purpose is to help understand the content of the present invention and implement it accordingly, those skilled in the art will understand that various substitutions, changes and modifications are possible without departing from the spirit and scope of the present invention and the appended claims. Therefore, the present invention should not be limited to the content disclosed in the best embodiment, and the scope of the present invention is subject to the scope defined in the claims.

Claims

1. A security audit method for a multi-chain collaboration scenario, comprising the following steps: 1) Perform security detection on the operating environment of the set nodes in each single-chain system to be connected to the multi-chain collaboration scenario, and proceed to step 2) after the detection passes; wherein, the set nodes include nodes used for block information synchronization or consensus participation, and nodes used for inter-chain transaction processing or verification; each single-chain system corresponds to a blockchain system; 2) Audit each of the single-chain systems in accordance with the audit method of the blockchain system, and add the single-chain systems that pass the audit to the multi-chain collaboration scenario; 3) Auditing the blocks, transactions and asset security of the multi-chain collaboration scenario; and auditing the consistency and availability of cross-chain transaction activities in the multi-chain collaboration scenario; wherein the auditing of the blocks, transactions and asset security of the multi-chain collaboration scenario includes: i) Check the correctness of block information, verifying whether the block information synchronized by the collaborative nodes in the multi-chain collaboration scenario is the same as the block information formed by the consensus mechanism of each single-chain system connected to the multi-chain collaboration scenario; If they are the same, the audit is passed; ii) Check the timeliness of block synchronization to verify whether the block information synchronization of the collaborative node has timed out. If there is no timeout, the audit is passed; iii) Transaction legitimacy check, verifying whether the transactions received or sent by the nodes participating in the cross-chain transaction have abnormal transaction parameters or abnormal results on the initiating blockchain and the receiving blockchain; if there is no abnormality, the audit is passed; iv) Conduct transaction validity checks to verify whether the transactions received or sent by the nodes participating in the cross-chain transaction have been executed on the initiating blockchain and the receiving blockchain and successfully written into the corresponding block ledger; if the execution is completed and written into the corresponding block ledger, the audit is passed; v) Cross-chain asset lock check, to check whether the time of cross-chain asset lock and unlock, asset quantity and permission setting conditions will cause some assets to be permanently locked or misappropriated, and whether the privacy of the relevant locked assets is consistent with the cross-chain mechanism design; when both the cross-chain code and historical transactions pass the cross-chain asset lock check, the audit is passed; vi) Security and reliability check of cross-chain assets. If both the cross-chain code and historical transactions pass the security and reliability check of cross-chain assets, the audit is passed; Auditing the consistency and availability of cross-chain transaction activities in the multi-chain collaboration scenario includes: A) Check the consistency of cross-chain transactions, verify the atomicity and uniqueness of the cross-chain transaction execution process, verify the rollback mechanism when each sub-transaction in the cross-chain transaction fails to execute, and verify whether the related transactions in the initiating blockchain and the receiving blockchain involved in the cross-chain transaction are successfully written into the block ledger and meet the final consistency conditions on multiple chains; B) Check the availability of cross-chain transactions, verify the isolation between the single-chain systems in the multi-chain collaboration scenario, verify whether each single-chain system has a processing mechanism for malicious nodes, and evaluate the availability of cross-chain services when malicious nodes exist; C) Compatibility check of cross-chain calling code, including checking whether the calling function exists and is available, whether the exception handling mechanism exists and is correct, and whether the function execution logic is consistent with the cross-chain mechanism design.

2. The method according to claim 1, characterized in that The compatibility check method of the cross-chain call code is: obtain the functions that need to call the other blockchain or are called by the other blockchain from the design document of the multi-chain collaboration scenario, check whether each of the functions exists and is available in each single-chain system in the multi-chain collaboration scenario, whether the calling and execution semantics of the relevant functions are consistent with the cross-chain mechanism design, and when the relevant function does not exist, whether the on-chain exception handling mechanism can correctly handle the calling error.

3. The method according to claim 1, characterized in that The method for checking the availability of the cross-chain transaction is as follows: building a test environment consistent with the multi-chain collaboration scenario; shutting down one or more single-chain systems in the test environment, and checking whether transaction activities not involving the shut-down single-chain systems are still executed normally, and whether transaction activities involving the shut-down single-chain systems have a timeout waiting or execution failure fallback mechanism that meets the requirements; for the audit of malicious nodes, deploy relevant malicious nodes in the test environment and attack one or more blockchain systems to check the relevant processing mechanisms of cross-chain services and under what circumstances cross-chain transaction services are still provided.

4. The method according to claim 1, characterized in that: The collaborative nodes include nodes for synchronizing block information, nodes participating in the consensus mechanism, nodes processing multi-chain transactions, and nodes participating in inter-chain verification.

5. The method according to claim 1, characterized in that: The operating environment includes a hardware environment and a software environment.

Images