Anyone with a non-trivial amount of bitcoins should consider multi-signature security, including how to mitigate potential attacks.
This is an opinion editorial by Anant Tapadia, a computer engineer and contributor to Bitcoin self-custody projects. Bitcoin Guardian and hex wallet.
Multi-signature security, or “multisig”, offers a different set of security guarantees than single-signature (singlesig) solutions. While I think singlesig is a great form of custody when one is just starting out with bitcoin or managing small amounts, in my opinion anyone who has a non-trivial amount of bitcoin for the long term should consider a multisig option.
Definition of multigrade
It is imperative to understand what we mean by “wallet” before making my case for one guy versus another. A multisig wallet is referred to as a “vault” in apps like Bitcoin Keeper and Blue Wallet, while some also refer to it as the “coordinator” or “coordinating software.” It’s basically a wallet that can talk to multiple signature devices and coordinate with each other to sign transactions (usually using the psbt format). By comparison, a singlesig wallet talks to only one signer. The singlesig wallet is also usually the signer, which means the keys are hot.
Therefore, the attack surface exposed due to a singlesig wallet and vault is similar, as they both have similar roles. Having a signature device in both cases increases security and introduces new attack surfaces.
A multisig is often referred to as “m-of-n”, where you need “m keys out of n” to sign a transaction. A exit descriptor either bitcoin secure multisig setup (BSMS) is a format used to define the configuration of a multisig. This can be used to recreate your configuration on other coordinators or to register the multisig with the signing devices.
Bitcoin Custody Considerations
minimize trust
The obvious benefits of having multiple signers are to reduce single points of failure and increase redundancy in your setup. With the help of common multisig attack examples below, I’ll explain why those attacks are applicable, even with singlesig custodial. However, with multisig, you can minimize trust in any entity, since multiple entities are involved.
Operational Effort
Setting up and using multisig can take more time operationally and include more difficulties if not done correctly. Therefore, I recommend that users only consider multisig for long-term HODLing, where regular transactions are not anticipated.
set costs
A solid multisig from multiple providers (such as one with three out of five custodial) can be achieved for anywhere between $250 and $600. So if you have around 0.5 BTC (about $11,000 as of this writing), spending less than 10% to insure it is not a bad idea, because the value of this bitcoin can appreciate very quickly.
Signature device costs are also coming down, for example, tap signer from Coinkite. Additionally, using non-hardware-based programmable keys gives you zero-cost options, but it is not recommended that they be used for more than one key in a multigrade setup.
Common Attack Mitigation
I will now discuss some attacks that can occur if a key escrow coordinator tries to act maliciously. I’ll then explain how this is no different from threats in a singlesig setup and what multisig wallets can do to mitigate these risks. Inevitably, the ultimate responsibility rests with the user to ensure that they take the appropriate steps, as suggested below.
The wrong receiving address
The most direct attack that I will describe is one in which the user tries to receive funds, and instead the coordinator application displays the address of the attacker. In such scenarios, the software could still show that the funds were received where the user intended. In theory, this attack is possible with any singlesig wallet because the user trusts the wallet to generate an address for them. There is no way to manually derive addresses from your 12 or 24 word recovery phrase.
In the case of a multisig wallet, this can be mitigated by checking the address on the signature devices where the multisig was registered. You can also use other coordinating software, import the same settings, and check the address that way.
Shipping address replacement
As in the previous attack scenario, a multisig coordinator can replace the address to which it tries to send funds while building the PSBT. The situation will be no different in the case of a normal singlesig wallet.
To mitigate this risk, the user is always advised to verify the address on signature devices. Since signing devices sign the transaction containing the recipient’s address (in PSBT format), it will display the address you are signing. Unless there is some collusion between the coordinator application and the signing devices, this is a great way to minimize trust in either one.
Change direction of change
A less obvious attack is one in which a coordinator application replaces the change address in your transaction. This means that the change from the transaction will go to the address of an attacker. Unlike the sending address, the user may not verify the address change when sending funds, making this attack less obvious. Again, no difference when it comes to a singlesig solution.
This is where multisig registration on signing devices is very necessary. If the registration is made, the signing device will not sign the transaction if it does not identify the change address.
Registry Alteration
Since the coordinator also coordinates the registration step, a different multisig can be registered so that the attacker controls “n” or more keys. In this case, the signing device will not be able to identify the receiving address or change the address correctly. The user will also see the same receiving address (the attacker’s) on the signing device, and the signing device will pass the change address as correct, since it has no way of confirming whether or not the other cosigners were tampered with. .
Therefore, it is recommended that there be “n” registered devices in your configuration. Also, confirm the configuration details on all those devices during registration. Another way to verify proper logging is to set up the same multisig in another coordinator software and check if it shows the exact details.
So you could have a multisig with a record vault signing device and two blind signers. Repeat the same process with another coordinator. Now, check the configuration on both the coordinators and the multisig record signing device. You can add more coordinators to the mix to rule out collusion.
rescue attack
This type of attack is similar to the previous one, but the attacker controls less than “n” keys, so he cannot control the backgrounds. But in a situation where he loses some of the keys, the attacker can hold him for ransom, since now he does not have the minimum quorum required. This attack can also be performed via key injection, where additional cosigners are added to the configuration. This has the same effect as replacing some of the co-signers.
Again, checking co-signer details across multiple coordinators that need registration will reduce the chances of these attacks.
Using multisig custody for your Bitcoin
To repeat: having a minimum quorum of signing devices registered to multisig and verifying transaction details (when you have to) would be a good rule of thumb when using multisig.
When checking addresses or vault configuration details, don’t just check the beginning and end of the string, as the attacker may have a similar-looking string.
Checking if the escrow application is open source and reviewing its code (if possible) is also a good idea for some. Support for common standards such as BSMS and PSBT ensures that the multisig configuration or transaction can be transferred to other applications for verification.
I also believe that one can never go wrong when testing the setup. Once you have your multisig ready, duplicate the setup on more coordinators. Receive a small amount in one app and send a part from another. Verify that the balances are correctly reflected on all coordinators after each step.
References and further reading:
This is a guest post by Anant Tapadia. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
