Attack and protection schemes on fabric isomorphic crosschain systems

Abstract

Crosschain solves the problem of value transfer and asset interaction between different blockchains with different consensus mechanisms, or different infrastructures. It not only realizes the mutual communication of multiple independent blockchains, but also ensures the data consistency. However, existing crosschain technologies like notary mechanism, hash locking, distributed private key control, and sidechain/relaychain have potential vulnerabilities, resulting in different kinds of attacks. For example, some vulnerabilities that only exist in a blockchain like DDOS, overflow, double-spending, and so on, may have an impact on another secure blockchain due to the openness of the crosschain system. Even if all blockchains are safe enough, the security of the crosschain system cannot be guaranteed, and there are still many loopholes in the process of crosschain, which affect all blockchains. The security of crosschain has emerged as an important issue. In this work, based on BitXHub, an open-source project of crosschain, we are motivated to study the security of Fabric isomorphic crosschain system. First, we analyze the vulnerabilities in different layers of Fabric isomorphic crosschain systems, and discuss the principles of different kinds of attacks. Based on the principles, we discover and define five new crosschain attacks, including crosschain integer overflow attack, crosschain transaction forgery attack, crosschain transaction replay attack, crosschain transaction sequence attack, and crosschain routing attack. Second, we implement all the five attacks, and indicate the applicable scenarios and the boundary conditions in which each attack may occur. Third, we propose five schemes to prevent the corresponding attacks and evaluate the effectiveness of the protection schemes. We comprehensively discuss and analyze the schemes of attacks and their corresponding prevention toward Fabric isomorphic crosschain systems.

SoK: Security and Privacy of Blockchain Interoperability [Extended Version]

“…Attackers can repeatedly submit the same inclusion proof over and over again to try to prove a statement more than once. Numerous unbacked assets can be created, or multiple tokens can be unlocked, triggered by a single burn event [58], [76], [92], [130], [176].…”

“…). Attackers might try to repeatedly submit the same inclusion proof over and over again to try to prove a statement more than once [58], [76], [92], [130], [176] -i.e., a Replay Attack. For instance, after locking an asset 𝑋 on the source chain, the attacker might present the corresponding Merkle proof multiple times to mint multiple representations of 𝑋 on the destination chain.…”

“…These solutions should be enforced by the overall protocol architecture -i.e., guarantee atomicity by design. It can be either enforced by decentralized watchers ( 21 ) [50], [135], centralized systems ( 8 ) [37], [73], [176], third-party networks with custom rules built-in to the consensus mechanism( 22 ) [188], or cryptographic primitives set up jointly between users and operators ( 23 ) [74], [98], [103], [105]. This vulnerability can also be inserted through a buggy smart contract implementation.…”

SoK: Security and Privacy of Blockchain Interoperability

“…). Attackers might try to repeatedly submit the same inclusion proof over and over again to try to prove a statement more than once [75], [89], [92], [130], [176] -i.e., a Replay Attack. For instance, after locking an asset 𝑋 on the source chain, the attacker might present the corresponding Merkle proof multiple times to mint multiple representations of 𝑋 on the destination chain.…”

“…These solutions should be enforced by the overall protocol architecture -i.e., guarantee atomicity by design. It can be either enforced by decentralized watchers ( 21 ) [50], [135], centralized systems ( 8 ) [37], [72], [176], third-party networks with custom rules built-in to the consensus mechanism( 22 ) [179], or cryptographic primitives set up jointly between users and operators ( 23 ) [73], [98], [103], [105]. This vulnerability can also be inserted through a buggy smart contract implementation.…”