BitGo TSS: A technical deep-dive

To validate and process any transaction on the blockchain, one must sign it digitally using special cryptographic keys. By design, whoever has those keys has the power to transact. That means it’s vital to keep your keys safe.

A number of providers have emerged to help individuals and institutions protect their keys. Each one employs a “digital signature scheme” to safeguard key information and therefore ensure that only authorized individuals can move funds.

An overview of Multi-Sig and TSS

Two of these security schemes rise above the rest: Multi-Sig (Multi-Signature Scheme) and TSS (Threshold Signature Scheme). Both of these schemes provide the security and the trust needed for keeping the keys safe, though with some differences in their mechanics.

Multi-Sig and TSS both create digital signatures using Public Key Cryptography. In this model, Public Key Cryptography relies upon public and private key pairs where the private key generates a unique signature that can only be authenticated by its public pair.

Both Multi-sig and TSS prevent a single point of failure by sharing secret, private key material among multiple participants. That means a malicious actor would need to attack multiple key holders to recover the private key.

One notable difference is that Multi-Sig uses multiple, distributed keys where a threshold of keys are needed to sign any transaction. In TSS, meanwhile, there is one key, split several ways and then distributed in a similar fashion. It also requires a threshold — ie, a minimum number of key shares needed to sign a transaction.

Understanding TSS

Utilizing the Distributed Key Generation protocol, TSS enables multiple parties to contribute to the key generation process. It also creates a digital signature without revealing the private key itself throughout the flow.

During a transaction, each participant generates a value destined for the others, then shares those values through multiple rounds. Combining the secret shares, each participant can then generate its own private key share. During signing, only the threshold number of participants need to come together to derive the final signature.

Throughout this flow, the private key is never constructed — meaning it is never exposed. A malicious actor would need to compromise at least as many participants as the threshold requires in order to recover the private key.

A widely used analogy for TSS is to find the average salary of a group of people without revealing an individual’s salary.

Let’s say there are 4 parties: Arnold, Bonnie, Chen, and Daniel. Arnold is making $45,000, Bonnie is making $41,000, Chen is making $53,000, and Daniel is making $27,000 — adding up to $166,000 in total.

Now, each party partitions their salary into 4 random numbers that sum up to their individual salary.

• Arnold partitions his salary into 4 random numbers, -1,000, 30,000, 1,000, and 15,000. Arnold shares 30,000 with Bonnie, 1,000 with Chen, and 15,000 with Daniel.

• Bonnie partitions her salary into 4 random numbers, 23,000, 7,000, 9,000, and 2,000. Bonnie shares 7,000 with Arnold, 9,000 with Chen, and 2,000 with Daniel.

• Chen partitions his salary into 4 random numbers, 5,000, 20,000, 25,000, and 3,000. Chen shares 20,000 with Arnold, 25,000 with Bonnie, and 3,000 with Daniel.

• Daniel partitions his salary into 4 random numbers, 3,000, 5,000, 10,000, and 9,000. Daniel shares 5,000 with Arnold, 10,000 with Bonnie, and 9,000 with Chen.

Next, they each assemble the shares they’ve been given by the others:

• Arnold sums up all the received numbers from each party with -1,000, which adds up to 31,000

• Bonnie sums up all the received numbers from each party with 23,000, which adds up to 88,000

• Chen sums up all the received numbers from each party with 5,000, which adds up to 24,000

• Daniel sums up all the received numbers from each party with 3,000, which adds up to 23,000

Finally, all the parties come together and sum the final values they calculated, which add up to 166,000. They then divide it by 4 to find the average salary: $41,500.

Arnold + Bonnie + Chen + Daniel = 166K

Without ever revealing anyone’s individual salary, the group was able to calculate their average salary.

TSS works in a similar way. The final signature — akin to the average salary in our example — can be generated by combining secret shares, which would be the random values generated by each party, without revealing each party’s private key share (which would be the individual salaries in our example above).

TSS should not be confused with Shamir’s Secret Sharing (SSS). In SSS, the private key is divided into pieces (sharded) and split between participants, as well. To sign a transaction, the shard holders come together to reconstruct the private key.

In SSS, the private key is constructed both during key generation and signing. This creates a potential vulnerability where an adversary might be able to expose and recover the private key with a man-in-the-middle attack.

TSS, however, eliminates this risk. Because it never constructs the private key itself at any point in the process — either during key generation or transaction signing — it’s immune from this particular vulnerability.

How TSS compares to Multi-Sig

TSS and Multi-Sig optimize for slightly different things.

Accountability: If the end-users want to know which parties participated in transaction signing, Multi-Sig wallets are a better fit. The blockchain records exactly which key was used, which can then be traced backwards. TSS, meanwhile, only records whether a threshold of key shares were used — not which ones, specifically. Therefore, there’s no direct, on-chain way to identify who participated in transaction signing.

Compatibility: Not every protocol supports Multi-Sig natively. For instance, BTC natively supports Multi-Sig scheme, thanks to its Pay to Script Hash (P2SH) standard in which the end-user can specify how many signatures are needed to move a transaction from an address — but this isn’t true for certain other blockchains.

If the protocol does not support Multi-Sig natively, one needs to create a smart contract to deliver the same capability. If the smart contract has not been well-audited it may be susceptible to vulnerabilities, such as the case of the Parity Wallets exploit in which ~$30M USD was stolen. It takes time to write smart contracts securely and get them audited, ideally by a 3rd party company, which tends to slow down the process for adding new coin support.

Cost: Multi-Sig transactions contain more data because they contain multiple signatures per transaction, which need to be stored and verified on-chain. TSS transactions, meanwhile, only contain one signature and bypass the need for additional smart contracts — thus less data on-chain. That makes TSS somewhat less costly compared to Multi-Sig in terms of gas fees.

Speed: Multi-Sig and TSS deliver comparable transaction speed. One might suspect that Multi-Sig could be slower since it produces multiple signatures that need to be verified on-chain. TSS, however, has its own hurdle, involving more roundtrips between participants to generate a transaction in the first place. In any case, it’s all a bit moot: The speed of a blockchain is usually constrained by its own protocol more than which signature scheme is used for a particular wallet.

Flexibility: TSS is more flexible for the providers to implement because it is more protocol-agnostic than Multi-Sig; it can be used for any blockchain without the need of smart contracts. Smart contracts need time to be developed and they need to be audited thoroughly. With TSS, any coin can be onboarded rapidly to web3 applications.

How BitGo’s TSS Solution Compares to Other MPC Solutions

While TSS derives from MPC (Multi-Party Computation) — an alternative security scheme — BitGo’s TSS solution addresses the following issues that plague some of the current MPC/TSS implementations on the market today:

Accountability. By its nature, TSS doesn’t show who signed a transaction on the blockchain. BitGo, however, maintains secure, detailed logs that record which key shares were used in a given transaction.

BitGo’s TSS solution follows our Multi-Sig model where there are User, BitGo, and BackUp key shares, respectively, and two of these shares need to come together to build a signature. We store logs within our platform of which of the three key shares were used during transaction signing and then secure these logs to make sure they are immutable.

Purpose-built technology. BitGo does not rely on a third-party solution to protect the BitGo key shares. Instead, BitGo has a dedicated R&D team to develop Hardware Security Modules (HSM) tailored for cryptocurrency.

By designing our HSMs, we protect ourselves from supply chain attacks. Nor do we blindly sign any transactions, which is a risk with traditional HSMs that were built for a pre-cryptocurrency world. Instead, BitGo’s purpose-built HSMs do additional checks on each transaction they receive before fully signing it and posting it to the blockchain.

Hybrid approach. BitGo does not solely rely on a certain technology to protect the key shares; we ensure business continuity through a diversified, hybrid approach in which different types of technologies store and protect key shares.

The BitGo key share — also known as the platform key share — stays under BitGo’s custody, and is protected by our purpose-built Hardware Security Module (HSM). The user key share, meanwhile, remains under the client’s custody.

The client technology protecting the user key share could be a TPM, an HSM, or any secure enclave deployed on the premises or the cloud. The backup key is protected offline for backup and disaster recovery purposes.

With a hybrid approach, BitGo prevents a single point of failure: If a vulnerability is discovered in a certain technology that protects the key material, the whole key material is at risk and thus so are the funds that are managed by that technology.

If the enterprise discovers the vulnerability before it is exploited, they need to find a patch as soon as possible and freeze their services until the patch is delivered. If a patch is not available, they need to find a new technology to migrate their key material, which may take months and result in service downtimes. BitGo solves this issue by not relying on a single technology protecting the TSS key shares.

BitGo’s hybrid approach also enables business continuity because the technologies we deploy to protect the key shares are geographically segregated. In the case of a natural disaster, relying on a single geographic location could end up losing all the client’s funds.

Peer review. Many TSS solutions haven’t been open-sourced and battle-tested, meaning they may have undiscovered vulnerabilities. Today, many companies rely on proprietary cryptography to cover up for the fact that they’ve rushed the work in an attempt to get to market faster. That means there may very well be vulnerabilities in cryptographic technology that can and will be exploited in the future — all thanks to insufficient testing and transparency.

Security expert Bruce Schneier argues that just because you can’t break the code you created doesn’t mean nobody can. Likewise, OWASP (the Open Web Application Security Project) says: “Proprietary encryption algorithms are not to be trusted as they typically rely on ‘security through obscurity’ and not sound mathematics. These algorithms should be avoided if possible.”

We’ve made ours open-source and started a bug bounty program to address this issue because we believe that’s the only way to ensure our customers’ security. Our tech is proven and battle-tested — you don’t have to take our word for it.

Backup keys. Some TSS implementations treat each key share the same and do not allocate any of them for backup purposes. However, the clients need to be able to sign transactions without the need for service providers. If the service provider is out of the picture because of a natural disaster, technology failure, or service downtime, the client still should be able to process their transactions.

Therefore BitGo allocates one of the key shares to be used for backup purposes under the custody of the client so that the users can process transactions with the user key shares and the backup key shares.

This also protects clients in cases where they lose a key share — for instance, if the holder of the user key share leaves the company, or a password gets lost. In such a case, the user could still use their backup key shares to sign transactions along with BitGo key shares.

To learn more about BitGo wallets, please contact sales@bitgo.com. To participate in our bug bounty program, please see our program page for more information.