Blind Signature Attacks on Tezos— A Reminder of “Do Not Trust, Verify”

If you are an active member of the Tezos community and follow closely the news on public forums (Reddit), social media (Twitter), and some media websites (Bitcoinexchange), you have probably heard about Blind Signature Attacks, maybe in relation to popular wallets, such as TezBox Wallet.

Although some wallets (TezBox, Galleon) announced their release of patches to protect against this vulnerability, I find it important for Tezos and other cryptocurrency owners to understand what a Blind Signature Attack is and how you can prevent it. This matters, as it is not specific to Tezos, but is a vulnerability that could be present in any wallet (or client) supporting any other digital asset. Furthermore, as most wallets are not open-source, there is no way of checking that the vulnerability has been patched. Nonetheless, there are ways you can prevent independently to what wallet developers do.

As the title shows, it is a great reminder to all members of blockchain communities of: “Do not trust, verify”.

What Are Blind Signature Attacks?

To understand Blind Signature Attacks, one must first have a grasp of what wallets are, how users interact with them and how they interact with a protocol, such as Tezos. In other words, let’s look at what happens under the hood when a user interacts with a wallet*. The diagram below is a simplistic representation of the components involved in the process of making a transaction with a wallet:

What happens under the hood when a user sends a transaction using a wallet

1. A user X, who owns XTZ, wishes to send a transaction to user Y.
2. X creates an account using one of the existing wallets and funds that account with XTZ.
3. With the wallet’s user interface, X initiates a transaction by choosing a destination of the funds and the amount.
4. The wallet takes the parameters inputed by X and makes a request, an RPC call to a full node.
5. The full node returns a response with the parameters that the wallet has sent, in addition to other information, such as nonce or gas. The response is in JSON format, sent back to the wallet.
6. The wallet does not verify the received JSON data and proceeds with signing the transaction.
7. The signed transaction is sent to the full node, to later be added to the mempool, eventually to be included on the blockchain.

*Note that I do not know the specifics on what each wallet actually does in the backend. I just want to explain the high level idea.

**Generally, wallets connect by default to full nodes that the wallet dev teams maintain, but normally a user can change to which full node they want to speak to.

So, Where is the Blind Signature Attack?

The attack occurs between step 5) and 6):

Full node has the ability to return a response that does not match the initial parameters

The full node has the ability to return JSON data which does not correspond to the parameters submitted by the user in step 3) and 4). For example, the user X might have requested to send 10 XTZ to Y but the JSON data returned by the full node instead sent 1000 XTZ to Z.

Because the wallet was not configured to verify the data received from the full node, before signing it, and unfortunately the user actually had enough XTZ in this account, this transaction will be submitted to the mempool and would proceed to be included in the blockchain.

As neither the wallet was configured for checking nor the user to verify, these signatures are referred as blind — thus, the name of the attack. As a result, X will lose 1000 XTZ thinking that he/she sent 10 XTZ to Y. A simple analogy would be as if user X was blindfolded and asked to sign a check.

How to Prevent Blind Signature Attacks on Tezos?

There are many ways of preventing Blind Signature Attacks, depending on what perspective we take.

Wallet developers could fix this issue by simply adding an additional step between step 5) and 6). In other words, add defend against potential malicious full nodes by adding the feature of verifying the JSON data that the full node returns to the wallet. With this additional verification step, the wallet could check that the parameters to address and amount effectively match the ones that the user initially inputed.

Users could defend themselves in many ways, depending on their preferences and how much convenience he/she is willing to sacrifice to gain additional security.

• Trusted Full Nodes: A way of defending against Blind Signature Attacks is by choosing a trusted full node. In this case, as the full node would not act maliciously, the user is not vulnerable to the attack, regardless of the wallet implementing the verification step or not. However, it must not only be a trusted full node, but also one where you are completely certain that has not been compromised. Unless you are a user who is running and maintaining your own full node and are 100% confident in the security, I would not recommend this option.
• Verify Wallets’ Code: In the case a wallet is open-source or users were able to obtain proof of the wallet being able to defend against the Blind Signature Attacks. Although motivating users to audit the code of applications they use would do great, this would require not only the knowledge and skill to perform the audit, but also the time.
• Leverage Hardware Wallets: At this point, both Ledger Nano S and TREZOR Model T enable users to defend themselves against Blind Signature Attacks, regardless of the wallet features. This is because when linking your hardware wallet to a software wallet (TezBox, Galleon, SimpleStaking, etc), it will require the user to verify the parameters before signing a transaction on the hardware wallet:

How Trezor Requires the User to Verify Every Parameter Before Signing a Transaction

Needless to say, it is still up to the user to spend those additional seconds to verify every single parameter before clicking or tapping on ✓.

Summary

Do not trust, verify.