Informal Systems interBTC Audit

We’re pleased to announce that Interlay has resolved two comprehensive audits from Informal Systems. These focused on the completeness of our protocol specifications (interbtc-spec, XCLAIM) and correctness of our implementations (interbtc, interbtc-clients). In this post we would like to share some of the findings and how they were resolved. As we prepare for our first release on Kusama we knew it would be important to share with the community for full transparency.

To fully understand the concepts presented herein, we’ll begin with a brief overview of the architecture of the interBTC/Kintsugi bridge. There are two primary actors in the system:

• Vaults are responsible for locking collateral (i.e. DOT / KSM) and keeping users’ BTC in custody.
• Users may mint interBTC/kBTC by locking BTC with a Vault or burn interBTC/kBTC to receive BTC on Bitcoin.

The bridge embeds a light-client (known as the BTC-Relay) which off-chain software must keep up-to-date in order for Bitcoin transactions to be verified.

Q2 Audit (2021/06/12)

Informal Audit Report

informal-report-interlay-audit-2021Q2.pdf

Scope

In addition to a deep-dive of the XCLAIM protocol, the following parachain pallets were audited:

• bitcoin
• btc-relay
• vault-registry

Findings

Informal identified three high, one medium and five low severity findings. They also suggested that the code and specification should be better aligned to eliminate a range of possible attacks. We have since overhauled the specification to include conditions that describe the expected state before and after transaction execution. We hope to transition to formal verification in the future.

Overpayment of Redeem Requests (IF-INTERLAY-THEFT)

One of the more critical findings detailed a deviation of the “locked BTC” and the interBTC issued by the same vault. To ensure the stability of our peg, vaults are required to hold the exact amount of BTC on Bitcoin as the amount if interBTC or kBTC minted on the bridge. A vault may be reported for theft if a valid fraud proof shows that the vault transferred BTC outside of the protocol.

A bug in our implementation allowed vaults to exfiltrate BTC through over-payment. Vaults were able to send more BTC than requested when a user redeems BTC for burning interBTC/kBTC. The root cause for this bug came from allowing users to over- and underpay BTC on issue requests. The verification function for both issue and redeem was the same. Ont he issue protocol, we use a user fail safe that allows users to mint less interBTF/kBTC than they requested as well as return BTC to the user if they submit more BTC than initially requested. For example, if a user requests issuance of 0.1 kBTC, but sends 1 BTC to the Vault, the Vault would return 0.9 BTC minus some fees.

However, using the same verification functions proved to introduce the security issue in the redeem protocol. We now enforce that Vaults submit exactly the BTC amount that was requested by the user on redeem.

Theft Reporting Improvement

After the disclosure of this vulnerability, we also identified a related attack concerning duplicate payments. To execute a redeem, refund or replace request a Vault must make a valid payment on Bitcoin with an OP_RETURN output that matches the request identifier. This prevents an attack where a Vault may submit stale data since the identifier is not known ahead of time. Whilst our theft reporting mechanism would ensure the correctness of a Bitcoin transaction, we did not check that a valid payment was already received. Hence, a Vault could make several similarly structured payments to exfiltrate BTC without detection. We identified two solutions to this problem, (1) store the Bitcoin transaction ID in the request object on the parachain or (2) provide a new extrinsic to report double payments (with the same OP_RETURN). It was realized that a malicious Vault would probably not execute the request if it had made several identical payments so we decided to implement the second solution.

Relay Inactivity

Another noteworthy finding related to relay (in)activity. As the safety of our on-chain software relies on the safety and liveness of off-chain activity it is entirely possible that the relay can be “offline” if it does not receive Bitcoin block headers. To prevent the unintentional expiry of on-chain requests (i.e. issue or redeem) we now store the chain tip when the request was made and expect a set number of child blocks.

Q3 Audit (2021/09/09)

Informal Audit Report

informal-report-interlay-audit-2021Q3.pdf

Scope

After the initial focus on the core modules, Informal proceeded to assess the (off-chain) vault client and the remaining pallets:

• issue
• redeem
• replace
• refund
• nomination

Findings

Informal identified one high, one medium and seven low severity findings. Additional emphasis was placed on the specification due to the updated architecture. All discrepancies have since been fixed and the specification is now properly aligned with the implementation. Unfortunately no specification was available for the vault client which limited the efficacy of the assessment but was noted for future work.

The only issue of note detailed a possible disagreement on expiration dates between the vault client and the bridge. Since the bridge was adapted from the Q2 audit to expect a certain number of relayed blocks before request expiry, the previous client implementation utilized the Bitcoin chain as the source of truth. Since the bridge uses the relayed headers, it was found that this view could be out-of-sync. This was a simple fix which involved switching to a bridge event subscription for finalized relay blocks.

Summary

Informal Systems identified eighteen findings and provided numerous additional recommendations to improve the clarity of our specification and code. All findings and most recommendations have since been resolved to ensure stability for launch.

We’d like to thank Josef Widder, Shon Feder and Cezara Dragoi for their hard work over the last few months. As the interBTC protocol continues to evolve, we look forward to future collaborations with Informal Systems. Over the next few months we also intend to run several bug bounties to incentivize community engagement.

In the true spirit of Kusama, “Expect Chaos”!

Stay tuned for more information on Interlay, interBTC and Kintsugi:

• Twitter: @interlayHQ @interBTC and @Kintsugi#BTC
• Discord: https://discord.com/invite/KgCYK3MKSf
• Telegram: https://t.me/interlay_community
• Or join our mailing list https://www.interlay.io/