BEP-171: Security Enhancement for Cross-Chain Module

[cosinlink]

  BEP: 171
  Title: Security Enhancement for Cross-Chain Module
  Status: Draft
  Type: Standards
  Created: 2022-10-28
  Author: cosinlink

BEP-171: Security Enhancement for Cross-Chain Module

• BEP 171: Security Enhancement for Cross-Chain Module
  • 1. Summary
  • 2. Motivation
  • 3. Specification
  • 4. Reference
  • 5. License

1. Summary

This BEP introduces several security enhancements for the cross-chain bridge between BNB Beacon Chain and BNB Smart Chain.

To further eliminate the pervasive effects of potential issues in cross chain module, it proposes the following enhancements:

• Upgrade IAVL proof verification to ICS23 spec.
• Apply timer lock to massive funds cross-chain transfer.
• Cross chain channels can be automatically paused by forged proof detection.
• Cross chain channels can be paused by any validator in an emergency.

2. Motivation

A full in-depth security review of BSC cross-chain bridge and Cosmos related codebase is done after the bridge exploitation. The community is still really concerned there could be potential security issues in the cross chain module. This BEP aims to：

• Share the same security level as CosmosHub by upgrading the old IAVL lib to the latest ICS23 implementation. The two teams(BNB-Chain and Cosmos) can consistently transmit security updates, best practices, and revised standards for secure operations.
• Exploitation automatic detection, quick action without human intervention.
• Increase the cost of the attack, like timer lock.

3. Specification

3.1 ICS23 Upgrade

ICS23 attempts to define a generic, cross-language, binary representation of merkle proofs, which can be generated by many underlying merkle tree storage implementations and validated by many client libraries over various languages. Currently, ICS23 provides a standard representation for proofs that accompany IBC (inter-blockchain communication) packets as defined in the cosmos specification. This BEP will abandon the stale raw IAVL merkle proof verification and upgrade to ICS23 specification.

3.2 Timelock

If the value of the cross chain transfer is larger than a predefined threshold, the funds will be locked in TokenHub for a fixed period before they can be withdrawn to the target account.
The default threshold of BNB is 10K, and the default lock period is 6 hours, both of them are governable. However, it is hard to set a proper threshold for other BEP20 tokens. We will grant the token owner permission to decide a proper threshold. The interface to set transfer threshold is as follows:

function setLargeTransferLimit(address bep20Token, uint256 largeTransferLimit) external onlyTokenOwner(bep20Token);

Once the funds are unlocked, anyone is able to withdraw the funds to the target account. The whitelist relayers will send the unlock withdrawal transaction by default to provide better user experience.

3.3 Exploitation Automatic Detection

The forged cross chain transaction shares the same channel and sequence with the real cross chain transaction, and both of them can be successfully verified by its merkle proof, while the payload of two transactions are different, such a trait can be used to detect forged cross chain packages.

3.3.1 Challenge

Anyone is allowed to submit a transaction to challenge the verified cross chain package on BSC. The interface is shown as below:

function challenge(uint64 height0, uint64 height1, uint64 packageSequence, uint8 channelId, bytes calldata payload0, bytes calldata proof0, bytes calldata payload1, bytes calldata proof1) onlyInit blockSynced(height0) blockSynced(height1) channelSupported(channelId) external;

Once the challenge passes the merkle proof verification, the cross chain contract will compare the hash of current payload0 and payload1. If the two payloads are different, it means one of the challenge packages is invalid, the cross chain communication will be suspended automatically.

3.3.2 Suspension in case of Emergency

The cross chain contract will be suspended if anyone succeeds in the challenge. Cabinet validators could also suspend the cross chain contract by sending a suspension transaction to the cross chain contract in case of emergency. After that, all cross chain channels will be suspended. The interface of this suspension transaction is shown as below:

function emergencySuspend() onlyCabinet whenNotSuspended external;

Withdrawals of large transfers will also be suspended during the suspension of cross chain. The cross chain contract could reopen through the validators by using the interface below:

function reopen() onlyCabinet whenSuspended external;

3.4 Cancel Cross Chain Transfer

The attacker's cross-chain transfer can be canceled by cabinet validators. The interface is shown as below:

function cancelTransfer(address receiver) onlyCabinet external;

The funds of this account in the timer lock will be returned to TokenHub to prevent someone minting tokens from nothing.

4. Reference

ICS23 spec: https://github.com/cosmos/ibc/tree/main/spec/core/ics-023-vector-commitments

5. License

All the content are licensed under CC0.