BitGo TSS：技术深度解析

要验证和处理区块链上的任何交易，必须使用特殊的加密密钥对其进行数字签名。根据设计，持有这些密钥的人就有权进行交易。这意味着确保密钥安全至关重要。

目前已涌现出多家服务提供商，致力于帮助个人和机构保护其密钥。每家服务商都采用"数字签名方案"来保护密钥信息，从而确保只有授权人员才能进行资金转账。

多签名（Multi-Sig）和 TSS 概述

其中有两种安全方案尤为突出：多签名（Multi-Sig）和阈值签名（TSS）。这两种方案都能提供保障密钥安全所需的安全性和可信度，尽管它们在具体机制上存在一些差异。

多签名（Multi-Sig）和 TSS 都利用公钥密码学生成数字签名。在此模型中，公钥密码学依赖于公钥和私钥对，其中私钥会生成一个唯一的签名，该签名只能通过其对应的公钥进行验证。

多签名（Multi-sig）和三方安全系统（TSS）都通过在多个参与者之间共享密钥和私钥材料来防止单点故障。这意味着，恶意攻击者必须同时攻击多个密钥持有者，才能恢复私钥。

一个显著的区别在于，多签名（Multi-Sig）使用多个分布式密钥，签署任何交易都需要达到一定的密钥阈值。而在 TSS 中，则只有一个密钥，该密钥被分割成若干部分，并以类似的方式进行分发。它同样需要达到一个阈值--即签署交易所需的密钥份额的最小数量。

了解 TSS

TSS 利用分布式密钥生成协议，允许多个参与方共同参与密钥生成过程。此外，它还能在整个流程中不泄露私钥本身的情况下生成数字签名。

在交易过程中，每个参与者都会生成一个分配给其他参与者的值，然后通过多轮分享将这些值传递出去。通过组合这些密钥份额，每个参与者随后可以生成自己的私钥份额。在签名过程中，只需达到阈值数量的参与者共同参与，即可生成最终签名。

在整个流程中，私钥从未被生成--这意味着它从未被泄露。恶意攻击者若要恢复私钥，必须控制的参与者数量至少要达到阈值要求。

关于 TSS 的一个常用类比是：在不透露个人薪资的情况下，计算一群人的平均薪资。

假设共有 4 个人：阿诺德、邦妮、陈和丹尼尔。 阿诺德的年收入为 45,000 美元，邦妮的年收入为 41,000 美元，陈的年收入为 53,000 美元，丹尼尔的年收入为 27,000 美元--总计 166,000 美元。

现在，每一方将自己的工资分成 4 个随机数，这 4 个数的和等于其个人工资总额。

• 阿诺德将自己的工资分成 4 个随机数：-1,000、30,000、1,000 和 15,000。 阿诺德将 30,000 分给邦妮，1,000 分给陈，15,000 分给丹尼尔。

• 邦妮将自己的工资分成 4 个随机数：23,000、7,000、9,000 和 2,000。邦妮将 7,000 分给阿诺德，9,000 分给陈，2,000 分给丹尼尔。

• 陈将自己的工资分成 4 个随机数：5,000、20,000、25,000 和 3,000。陈将 20,000 分给阿诺德，25,000 分给邦妮，3,000 分给丹尼尔。

• 丹尼尔将自己的工资分成 4 个随机数：3,000、5,000、10,000 和 9,000。丹尼尔与阿诺德分享 5,000，与邦妮分享 10,000，与陈分享 9,000。

接下来，他们各自将其他人分配给自己的股份整合起来：

• 阿诺德将各方收到的所有数字与-1,000 相加，总和为 31,000

• 邦妮将各方提供的所有数字分别与 23,000 相加，总和为 88,000

• 陈将从各方收到的所有数字分别与 5,000 相加，总和为 24,000

• 丹尼尔将从各方收到的所有数字与 3,000 相加，总和为 23,000

最后，各方聚在一起，将各自计算出的最终数值相加，总和为 166,000。随后，他们将该数值除以 4，得出平均工资：41,500 美元。

阿诺德 + 邦妮 + 陈 + 丹尼尔 = 16.6 万

该团队在未透露任何人的具体薪资的情况下，成功计算出了他们的 平均 工资。

TSS 的工作原理与此类似。最终签名--类似于我们示例中的平均工资--可以通过组合秘密份额来生成，这些秘密份额即各方生成的随机值，同时不会泄露各方的私钥份额（在上述示例中即为各自的工资）。

TSS 不应与沙米尔的秘密共享（SSS）相混淆。在 SSS 中，私钥同样会被分割成多个片段（分片），并分配给各参与者。要对交易进行签名，各分片持有者需共同协作以重建私钥。

在 SSS 中，私钥既在密钥生成过程中生成，也在签名过程中生成。这会造成一个潜在的安全漏洞：攻击者可能通过中间人攻击暴露并恢复私钥。

然而，TSS 消除了这一风险。由于它在整个过程中--无论是密钥生成还是交易签名阶段--都从未自行生成私钥，因此不会受到这一特定漏洞的影响。

TSS 与多签名（Multi-Sig）的对比

TSS 和多签名（Multi-Sig）在优化方向上略有不同。

问责制：如果终端用户想知道哪些方参与了交易签名，多签名（Multi-Sig）钱包是更合适的选择。区块链会精确记录使用了哪把密钥，从而可以追溯来源。而 TSS（阈值签名）仅记录是否使用了达到阈值的密钥份额，并不具体记录是哪几把密钥。 因此，无法通过链上直接方式识别参与交易签名的具体方。

兼容性：并非所有协议都原生支持多签名。例如，比特币（BTC）原生支持多签名方案，这得益于其"支付至脚本哈希"（P2SH）标准--该标准允许终端用户指定从某个地址发起交易所需的签名数量；但其他某些区块链则并非如此。

如果该协议本身不支持多签名（Multi-Sig），则需要创建一个智能合约来实现相同的功能。如果该智能合约未经充分审计，可能会存在安全漏洞，例如 Parity 钱包漏洞利用 其中约$30M USD 被盗。要安全地编写智能合约并对其进行审计（最好由第三方公司进行）需要时间，这往往会延缓新增代币支持的进程。

成本：多签名（Multi-Sig）交易包含更多数据，因为每笔交易中包含多个签名，这些签名需要在链上进行存储和验证。而 TSS 交易仅包含一个签名，且无需额外的智能合约--因此链上数据量较少。这使得 TSS 在 gas 费用方面比多签名交易略微便宜一些。

速度：多重签名（Multi-Sig）和 TSS 的交易速度相当。人们可能会认为多重签名可能会更慢，因为它会生成多个需要在链上验证的签名。然而，TSS 也有其自身的障碍，即在生成交易之初，参与者之间需要进行更多的往返通信。 无论如何，这些讨论其实有些多余：区块链的速度通常更多地受其自身协议的限制，而非特定钱包采用哪种签名方案。

灵活性：与多签名（Multi-Sig）相比，TSS 更不依赖具体协议，因此服务提供商在实施时具有更大的灵活性；它可用于任何区块链，且无需智能合约。智能合约的开发需要时间，并且必须经过彻底的审计。借助 TSS，任何代币都能快速接入 Web3 应用程序。

BitGo 的 TSS 解决方案与其他 MPC 解决方案的对比

虽然 TSS 源自 MPC（多方计算）--一种替代性安全方案--但 BitGo 的 TSS 解决方案解决了当前市场上某些 MPC/TSS 实现所面临的以下问题：

问责制。由于 TSS 的特性，它不会显示区块链上交易的签名者是谁。不过，BitGo 会维护安全且详细的日志，记录特定交易中使用了哪些密钥分量。

BitGo 的 TSS 解决方案遵循我们的多签名（Multi-Sig）模型，该模型中分别包含用户、BitGo 和备份密钥份额，其中需要将其中两个份额组合起来才能生成签名。我们在平台内记录交易签名过程中使用了哪三个密钥份额，并确保这些日志的安全性，以保证其不可篡改。

专为特定用途设计的技术。BitGo 并不依赖第三方解决方案来保护 BitGo 密钥份额。相反，BitGo 拥有一支专门的研发团队，负责开发专为加密货币量身定制的硬件安全模块（HSM）。

通过自主设计硬件安全模块（HSM），我们能够防范供应链攻击。此外，我们也不会盲目签署任何交易--这是传统 HSM 存在的一项风险，因为这些设备是为加密货币出现之前的时代设计的。 相反，BitGo 专为加密货币设计的安全模块（HSM）会在接收每笔交易后进行额外核查，确认无误后才会完成签名并将其写入区块链。

混合方法。BitGo 并非仅依赖某项特定技术来保护密钥份额；我们通过一种多元化的混合方案来确保业务连续性，该方案利用不同类型的技术来存储和保护密钥份额。

BitGo 密钥份额（也称为平台密钥份额）由 BitGo 托管，并受到我们专为该目的设计的硬件安全模块（HSM）的保护。与此同时，用户密钥份额则由客户自托管。

用于保护用户密钥份额的客户端技术可以是 TPM、HSM，或是部署在本地或云端上的任何安全隔离区。备份密钥会离线保护，以满足备份和灾难恢复的需求。

通过采用混合方案，BitGo 避免了单点故障：如果发现某种用于保护密钥素材的技术存在漏洞，整个密钥素材都会面临风险，因此由该技术管理的资金也会面临风险。

如果企业在漏洞被利用之前就发现了该漏洞，则需要尽快找到补丁，并在补丁发布前暂停服务。如果没有可用补丁，则需要寻找新技术来迁移密钥素材，这可能需要数月时间，并导致服务中断。 BitGo 通过不依赖单一技术来保护 TSS 密钥份额，从而解决了这一问题。

BitGo 的混合方案还能确保业务连续性，因为我们用于保护密钥份额的技术在地理上实现了分离。一旦发生自然灾害，如果仅依赖单一地理位置，可能会导致客户的所有资金损失殆尽。

同行评审。许多 TSS 解决方案尚未开源，也未经实战检验，这意味着它们可能存在尚未被发现的漏洞。 如今，许多公司依赖专有加密技术来掩盖其为尽快推向市场而仓促完成开发的事实。这意味着加密技术中很可能存在漏洞，这些漏洞未来极有可能被利用--这一切都归咎于测试不足和透明度欠缺。

安全专家 布鲁斯.施奈尔 认为，仅仅因为...... 你 无法破解你创建的密码，并不意味着 没人 可以。同样地， OWASP （开放 Web 应用程序安全项目）指出："专有加密算法不可信，因为它们通常依赖于'隐蔽性安全'而非严谨的数学原理。应尽可能避免使用这些算法。"

我们已将我们的项目开源，并启动了一个 漏洞赏金计划 为了解决这个问题，因为我们相信这是确保客户安全的唯一途径。我们的技术经过验证且经受过实战考验--您不必仅凭我们的说法就相信。

备份密钥。某些 TSS 实现方案将每个密钥份额一视同仁，不会为备份目的分配任何密钥份额。然而，客户端必须能够在无需服务提供商参与的情况下对交易进行签名。如果服务提供商因自然灾害、技术故障或服务中断而无法提供服务，客户端仍应能够处理其交易。

因此，BitGo 将其中一份密钥份额分配给客户保管，作为备份用途，以便用户能够使用用户密钥份额和备份密钥份额进行交易。

这还能在客户丢失密钥份额时提供保护--例如，当用户密钥份额的持有者离开公司，或者密码丢失时。在这种情况下，用户仍可使用其备份密钥份额，配合 BitGo 的密钥份额对交易进行签名。

如需进一步了解 BitGo 钱包，请联系 sales@bitgo.com。如需参与我们的漏洞赏金计划，请参阅 我们的项目页面 如需了解更多信息