作者:salvatoshi

来源:https://delvingbitcoin.org/t/state-minimization-in-musig2-signing-sessions/626

BIP-0327 以巨大篇幅讨论了在运行 MuSig2 签名会话时保存一些状态的必要性。然而,在 BIP-0327 中, “签名会话” 仅仅是 “产生一个签名的过程”。

在一个钱包的标准签名流程中,将 “会话 ”理解为完整签名一笔交易的过程,会更加合理。有可能一笔交易的所有输入,都会通过同一次 “descriptor containing musig()” 来获得,而签名者会一次性为所有输入产生 nonce 公开值(pubnonce)/签名。

因此,在 BIP-0327 流程中,你需要预期同一时间 每个输入都会激活至少一个 MuSig2 会话。在考虑硬件签名设备的支持时,这就在一定程度上带来了挑战:这需要为无法限制数量的签名会话持久保存状态,比如,一个钱包要接收大量小额 UTXO 的时候。可持久保存信息的存储空间,对嵌入式的硬件签名设备来说通常是稀缺资源;而草率的方法很可能就是根据硬件本身的限制,给交易的输入数量施加一个上限。

在这篇文章中,我草拟了一种方法,兼容于且建基于 BIP-0327,旨在定义一种只需在设备上持久化存储少量状态的 PSBT 层面的会话。这一方法通过为每一个单独的 MuSig2 会话同步生成必要的状态,将花费自 MuSig 钱包的 PSBT 的签名流程补充完整了。

使用同步随机性的签名流程

BIP-0327 状态的同步生成

本节将介绍本方法的核心思想,而下一节会在签名设备的语境下提供更精确的描述。

在 BIP-0327 中,签名设备需要保存的内部状态本质上是 secnonce(nonce 秘密值),该值又是让一个随机数 rand’ 进入 NonceGen 算法计算出来的,并且可以选择加入其它依赖于被签名交易的参数。

而本方法的核心思想是,计算出一个全局的随机数 rand_root;然后,为第 i 个输入和 “wallet policy” 所定义的、设备需要用于签名的第 jmusig() 密钥定义出用在 NonceGen 中的 *rand’*:

$$rand_{i,j} = SHA256(rand_root||i||j)$$

在拼接过程中,为了避免混淆,ij 使用固定长度的编码。这个数值将在 NonceGen 算法中作为对应的 输入/公钥 对的 rand’ 值。

参数 j 使我们可以处理包含了涉及相关签名设备多于一个 musig() 公钥表达式的 wallet policy。

签名流程的细节

本节介绍的是 PSBT 层面会话的处理,它将在 BIP-0327 的默认签名流程基础上插入。

我们假设签名设备要处理一个 PSBT 层面的会话;这个流程可以推广到处理多个并行的 PSBT 层面会话,每个会话都会计算和存储一个单独的 rand_root

在下列段落中,“会话 ”一词总是指代 PSBT 层面的签名会话;一个会话包含自身的 rand_root,可能还包含签名设备希望在处理签名过程中保存的其它辅助数据。

第一阶段:nonce 公开值的生成

一个 PSBT 发送给一个签名设备,该 PSBT 不包含任何 nonce 公开值。

  • 如果已经存在一个会话,将在持久化内存中删除旧会话。
  • 在易失性内存中创建一个新会话。
  • 设备产生一个刷新的随机数 $rand_root$,并保存在当前会话中。
  • 设备为第 $i$ 个输入和第 $j$ 个公钥生成随机性:$rand_{i,j} = SHA256(rand_root||i||j)$。
  • 根据 NonceGen 算法计算每一个 (secnonce, pubnonce)
  • 在完成阶段(所有的 pubnonce 都已返回之后),会话的秘密值 $rand_root$ 复制到持久化内存。

第二阶段:碎片签名的生成

一个 PSBT,包含了所有的 nonce 公开值,发送到设备。

  • 会话的一个复制本存储到易失性内存,然后该会话从持久化内存中删除。
  • 对每一个 输入/musig 公钥对 $(i,j)$:
    • 使用上述的同步随机性算法 $rand_{i,j}$ 重新计算 nonce 公开值/nonce 秘密值
    • 验证包含在 PSBT 中的 nonce 公开值与重新同步计算出的值相匹配。
    • 根据 BIP-0327 继续签名流程,生成签名碎片。

安全考量

避免状态复用

仅在第一阶段的结尾存储会话到持久化内存中,并且在第二阶段开始之前就删除它,可以简化审计,并确保不会出现跨签名会话的状态复用。

同步随机性的安全性

同步生成 $rand_{i,j}$ 并不是问题,因为 $rand_root$ 的值是秘密的,而且不会离开设备。这保证了不同的 $i$ 和 $j$ 所生成的数值对攻击者来说是不可预测的。

PSBT 的熔融性

如果要给 NonceGen 函数传入可选的参数 ,它们将依赖于 PSBT 中呈现的交易数据。因此,无法保证它们会在下一次到来的 PSBT 中保持不变。

但是,这并不构成一个安全风险,因为这些参数在 NonceGen 函数中只是额外的熵源。恶意的软件钱包无法以可预测的方式影响 nonce 秘密值/公开值。改变任何用在 NonceGen 中的参数都会导致第二节点出错,因为重新计算出的 nonce 公开值 将与 PSBT 中的不一致。

(译者注:即,PSBT 中包含的 nonce 公开值是签名设备在第一阶段中计算出来的;而第二阶段传入的 PSBT 中如果使用了不同的交易数据,设备将根据这些交易数据计算出不同的 nonce 公开值。)

推广到多个 PSBT 签名会话

上述方法假设了,在处理一个会话的时候,不会为包含了 musig() 公钥的一个 wallet policy 的另一个 PSBT 启动签名。

但可以将这种方法推广到任意数量的并行签名会话。每个会话都可以通过哈希(在实用性上)足以唯一定义被签名交易的信息(保证出现在第二阶段的 PSBT 所提供的信息未改变)来计算出一个 会话 id,从而区别每一个会话;举个例子,可以是对 PSBT 所包含的待签名交易的 txid 以及用于签名的 wallet policy 的承诺。

致谢

感谢 Yanick Seurin 在该话题上的不计其数的讨论,以及对本文草稿的审核。错误由我自己负责。