作者：Mr.Hodl
有时候，人们无法回答这个问题时，就会说 “那你就用多个厂商的设备搭建多签名吧”。这个问题是这样的：你怎么知道你的签名设备正在做的事情就是它自己说的那样？
多年以来，一直有一种答案是说，那你就把信任分散在多个硬件签名器厂商吧。如果你不能完全信任某一个实现，那么就使用多个。不同的制造商、不同的固件、不同的供应链。这其中的想法是：它们不太可能在同一时间因为相同的原因而出故障。这是一种有效的对冲。但依然只是对冲。它并不能直接告诉你，你手上的签名器到底有没有正确地工作。
这其中的区别是有意义的，因为多签名解决了一些真实的问题，但签名器的验证是另一个问题。
多签名解决协作问题
当多个人要一起控制一个金库时，多签名是极其有用的。只要密钥需要放在不同的的地理位置，它都是有用的。它可以对抗一个密钥丢失和暴露的风险。它对公司、家庭办公室、董事会、合作式托管以及不应该由一个签名器掌握所有权限的其他情形都有用。这些是写作、冗余和权限控制的问题。
但如果你的威胁模型很简单：“我的硬件签名器会不会对我说谎呢？”，加入另一个硬件签名器并不能说明第一个签名器是好的。它只是要求你信任另一个签名器实现。
直接验证
我现在更感兴趣的是直接验证。PSBT解析这东西已经不算新事物了。Bitcoin Core 和其他比特币软件早就能够解码和检查 PSBT 了。你可以自己检查输入、输出、金额、手续费、脚本、派生路径信息以及其它交易数据。但这里有一个更深的问题：在创建签名的时候，签名器实际上做了什么？
（译者注：“PSBT（待签名的比特币交易）” 是一种有规范的文件格式，用于承载待签名的交易的信息，可用于在软件钱包和签名器之间传递信息。）
这就是我们 EntrypyLab 一直在努力的方向。EntropyLab 已经可以检查 ECDSA 签名有没有 nonce 复用。这很重要，因为在 ECDSA 中，同一私钥重复使用同一 nonce 来签名不同消息会导致你的私钥泄露。 给验证器加载私钥，EntropyLab 可以为受支持的 ECDSA 输入独立重新计算预期的 RFC 6979 签名动作，包括 Bitcoin Core 风格的低 r 研磨。
（译者注：“RFC 6979” 是一套互联网标准，规定在 ECDSA 签名中，使用待签名消息来生成签名的 nonce ，从而让 nonce 的生成是确定性的，解决签名 nonce 复用问题 —— 理论上，只要签名的是不同的消息，就不会使用同样的 nonce 。“低 r 研磨” 是指，ECDSA 签名中的 r 值是 nonce 值的 x 坐标，一些 r 值只需要 32 字节来表达，另一些却需要 33 字节，一些软件实现会不断换用 nonce 值来签名，直到找出可以用 32 字节来表示的 r 值。）
这里面的区别是重要的。两者匹配并不能证明一个硬件签名器是值得信任的。它告诉你的仅仅是，这个签名与 EntropyLab 独立重新计算出来的确定性签名动作是一致的。不匹配也不必然表明这个签名器是恶意的。一个诚实的签名器也可能使用另一种有效的 nonce 构造，或者包含了额外的随机性。但出现了不匹配就表明有需要调查的地方。而 nonce 复用就是一个更强、强得多的证据。如果同一个 ECDSA nonce 出现在了它不应该出现的地方，那就不是硬件签名器开发哲学上的分歧了，而是一个密码学问题。
EntropyLab 也可以验证 Jade 的 “anti-exfil” 记录，在可以得到所需的信息的时候。anti-exfil 本身是从另一个方向解决我们这里说的问题（译者注：指签名器可能不值得信任）。主机不是在事后检查结果，而是在签名器签名过程中就为之提供信息，从而一个恶意的签名器更难将私钥数据编码在 nonce 公开值中。这是有用的。但我认为，有一个更重要的方向，比 nonce 分析更广泛。
PSBT 签名器审计
我们正在给 EntropyLab 合并一种叫做 “PSBT 签名器审计” 的特性。这想法很简单。你保存发送给硬件签名器的 PSBT。然后签名器返回 PSBT 。EntropyLab 会对比这两个文件，作为对签名的审计。交易的输入有没有变化？输出有没有改变？数额或者 UTXO 宣言有没有改变？签名器有没有替换 sighash 策略？有没有预料之外的公钥参与了签名？签名有没有被验证过？签名器有没有敲定一些不应该被分配给经过验证的签名的东西？派生元数据有没有改变？有没有出现专有的或者未知的字段？假定的找零输出真的属于你的钱包吗？Nonce 检查有没有发现复用？可用的 anti-exfil 检查有没有出错？
检查的策略设计成出错就关闭。如果一个签名没有经过检查，就不会被视为有效签名。如果验证的资源预算用尽，审计也不会静默让人以为成功。弱的 sighash，比如 NONE、SINGLE 和 ANYONECANPAY ，会被当成一个问题，除非最初的 PSBT 显式要求这样签名。最终的定稿会用验证过的签名材料来检查。元数据变更会显示出来，而不是悄悄忽视掉。找零输出可以用钱包信息来检查（只要提供了这些信息）。Nonce 和 anti-exfil 分析会变成整体审核的一部分。
这将是跟 “盯着硬件签名器的屏幕、祈祷固件没有出错” 完全不同的安全模式，。签名器是一个元素，验证器是另一个元素。它们不必相互信任。
我们也在扩充为人 PSBT 定稿的测试套件，使用一个独立的比特币实现。这也有意义，因为一个只自己验证的验证器算不上什么好的验证器。我们的目标不是开发出一个系统，让 EntropyLab 说 “EntropyLab 同意 EntropyLab”。目标是在多个独立实现之间对比动作，然后将不一致暴露出来。
多签名并不过时
这些验证技术并不表示多签名装置没有意义了。绝不是这个意思。如果三个人要运营一个金库，需要两个许可，那就要使用多签名。只要你希望把密钥放在不同的地方，就使用多签名。想要丢失一个签名设备并不威胁钱包，一个妥善设计的多签名装置可以给你冗余。如果不应该有某个人可以独自移动资金，那就是多签名这种方案要解决的问题。
但是，“我担心我的硬件签名器可能对我说谎” 并不天然是多签名要解决的问题。它是一个验证问题。而验证正变得越来越容易直接运行。
多设备的成本
这也是多签名的一个成本。更多种子、更多设备、更多描述符和钱包策略信息，都需要保存。更长的复原流程。更多协作。更多用户没有搞懂要备份什么、保存什么的概率。对于专业的用户和阻止，这些成本是很容易接受的。但如果一个人只是因为别人告诉他使用多个厂牌的设备会更安全，就买下三个硬件签名器，那可能是在为可以用别的办法解决的问题而支付复杂性代价。
验证交易、验证签名、验证 sighash、检查签名器的身份、检查找零输出、检查 nonce 动作（在签名方案允许的时候）。对比进入签名器的东西与返回的东西。如果你能用验证来替代一部分信任，就别把信任换成更多信任。
局限性
这种方向也是有局限性的。EntropyLab 并不是一款硬件签名器，并不签名交易。RFC 6979 重运算需要访问私钥，这就意味着更深的验证需要在更妥善隔离的环境中运行。这确实是一种取舍。RFC 6979 分析会应用在得到支持的 ECDSA 签名路径上。Taproot 使用 Schnorr 签名，nonce 使用规则也不一样。Nonce 不匹配并不是一个签名器已被攻破的证据。签名器审计也不能覆盖所有的固件、硬件和供应链攻击的可能性。而且，验证也无法消除为协作、冗余和权限控制而使用多签名的理由。
检查签名器干了什么
但这个方向正变得更加清晰。多年来，对不确定性的回答就只有一个：倍增。更多设备、更多厂商、更多密钥。有时候，这是正确的答案。但也有一些时候，真正的答案更加简单。那就是检查签名器实际做了什么。验证打败倍增。
（完）