阈值签名方案中共享密钥的破解

今天，我们披露了一个拒绝服务漏洞，该漏洞影响了基于 Frost、DMZ21、GG20 和 GG18 协议的多个阈值签名方案实现中的 Pedersen 分布式密钥生成（DKG）阶段。该漏洞允许单个恶意参与者秘密地提高重建共享密钥所需的阈值，这可能导致使用共享密钥生成的签名无效。

去年，我们在与 Chainflip 的客户合作中首次意识到这个漏洞。当我们审查 Chainflip 对 Frost 阈值签名方案的实现时，我们注意到它在做一些不寻常的事情——一些我们以前从未见过的。通常，这些类型的观察表明代码库中存在弱点或漏洞，但在这种情况下，Chainflip 的防御性编码实践实际上最终保护了其实现免受漏洞的侵害。通过格外小心，Chainflip 还避免在代码库中引入漏洞，单个参与者可以利用该漏洞来破坏在协议的密钥生成阶段创建的共享密钥。当我们意识到这一点时，我们开始好奇其他实现是否存在此问题。这开始了一项漫长的调查，最终导致了十项独立的漏洞披露。

什么是 Pedersen DKG 协议？

该漏洞实际上非常容易理解，但为了能够解释它，我们需要了解 Pedersen DKG 协议背后的一些数学细节。不用担心——如果你理解什么是多项式，你就应该没问题，如果你之前听说过 Shamir's secret sharing，那么你已经完成了大部分工作。

Pedersen DKG 协议基于 Feldman’s verifiable secret sharing (VSS) 方案，它是 Shamir’s secret sharing scheme 的扩展。Shamir 的方案允许 n 方共享一个密钥，然后该密钥可以由 t + 1 方重建。（在这里，我们假设该组已提前以某种方式就阈值 t 和组大小 n 达成一致。）Shamir 的方案假定存在可信的 dealer，并且不适用于多方计算方案，在这些方案中，参与者可能会受到威胁并恶意行事。这就是 Feldman 的 VSS 方案的用武之地。在 Shamir 的方案的基础上，它允许参与者验证份额是否是诚实生成的。

令 G 为离散对数问题很难解决的交换群，令 g 为 G 的生成元。在 (t, n)-Feldman VSS 上下文中，dealer 生成一个随机的 t 阶多项式 p(x) = a0 + a1 x + … + at xt，其中 a0 表示要共享的原始密钥。然后，她计算单个密钥份额作为 s1 = p(1), s2 = p(2), …, sn = p(n)。这部分与 Shamir 的方案完全相同。为了允许其他参与者验证他们的密钥份额，dealer 发布值 A0 = ga0, A1 = ga1, …, At = gat。然后，参与者可以使用系数承诺 (A0, Ai, …, At) 通过如下“在指数中”重新计算 p(i) 来验证他们的密钥份额 si：

• 计算 V = gp(i) = g s i。
• 计算 V’ = gp(i) = ga0 + a1 i + … + at i t = ∏k (gak) i k = ∏k Aki k。
• 检查 V = V’。

与 Shamir 的密钥共享一样，可以使用 Lagrange interpolation 通过 t + 1 个份额恢复密钥 s = a0。

在 Feldman 的 VSS 方案中，共享密钥对于 dealer 是已知的。为了生成协议的所有参与者都未知的共享密钥，Pedersen DKG 协议本质上并行运行 n 个 Feldman 的 VSS 方案实例。结果是 (t, n)-Shamir 的密钥共享，该值对所有参与者都是未知的：每个参与者 Pi 首先生成一个随机的 t 阶多项式 pi(x) = ai,0 + ai,1 x + … + ai,t xt。她发布系数承诺 (Ai,0 = gai,0, Ai,1 = gai,1, …, Ai,t = gai,t)，然后将密钥份额 si, j = pi(j) 发送给 Pj。（请注意，索引 j 必须从 1 开始，否则 Pi 最终会泄露她的密钥值 ai,0 = pi (0)。）Pj 可以通过如上计算 V 和 V’ 并检查它们是否一致来检查密钥份额 si, j 是否已正确计算。为了获得他们的密钥份额 sj，每个参与者 Pj 只是将从其他参与者获得的密钥份额相加。也就是说，他们将他们的密钥份额计算为

sj = s1, j + s2, j + … + sn, j = p1(j) + p2(j) + … + pn(j)

请注意，如果我们将 p(x) 定义为多项式 p(x) = p1(x) + p2(x) + … + pn(x)，很容易看出我们最终得到的是 p(x) 的常数项 s = p(0) = a1, 0 + a2, 0 + … + an, 0 的 Shamir 密钥共享。由于每个多项式 pi(x) 的阶数为 t，因此 p(x) 的阶数也为 t，我们可以像以前一样使用 Lagrange 插值法，通过 t + 1 个份额恢复密钥 s。

（在实现 Pedersen DKG 协议时，还需要考虑更多因素，但它们与此无关。有关更多详细信息，请参阅引言部分中链接的任何论文。）

在 Pedersen DKG 中移动目标

现在，我们准备好回到与 Chainflip 的合作，这个合作开启了这一切。在审查 Chainflip 的 Frost 签名方案的实现时，我们注意到该实现正在对最高系数 A1,t + A1,t + … + An,t 的承诺求和，并检查结果是否等于 G 中的单位元素，这意味着结果多项式 p(x) 的最高系数为 0。这显然是不希望的，因为它将允许少于 t + 1 个参与者恢复共享密钥，但是发生这种情况的概率在密码学上可以忽略不计（即使有恶意参与者）。通过检查，Chainflip 将此概率降低到 0。

这让我们想知道，如果参与者在 Pedersen DKG 协议中使用阶数与 t 不同的多项式 pi(x) 会发生什么？特别是，如果参与者使用阶数 T 大于 t 的多项式 pi(x) 会发生什么？由于 p(x) 等于总和 p1(x) + p2(x) + … + pn(x)，因此 p(x) 的阶数将为 T 而不是 t，这意味着签名协议将需要 T + 1 而不是 t + 1 个参与者才能成功完成。如果其他参与者未检测到此更改，它将允许任何参与者通过选择严格大于参与者总数的阈值来秘密地使共享密钥无法使用。如果 DKG 协议用于生成作为阈值签名方案（如引言中引用的方案之一）的一部分的共享密钥，则任何尝试使用 t + 1 个参与者对消息进行签名的尝试都会失败。根据实现，当检测到故障时，这也可能导致系统将恶意行为错误地归因于诚实的参与者。更严重的是，此攻击还可用于使基于 Feldman 的 VSS 的大多数密钥共享方案中的共享密钥无法使用且无法恢复。这包括 CGGMP21 和早期版本的 Lindell22 中描述的密钥共享方案。在这种情况下，共享密钥可能已经控制了大量的资金或Token，这些资金或Token将无法挽回地丢失。

显然，通过简单地检查每个参与者发布的系数承诺向量 (Ai,0, Ai,1, …, Ai,T) 的长度，以及如果发现任何长度与 t + 1 不同则中止，可以防止此类恶意行为。事实证明，Chainflip 已经检查了这个，但我们很好奇其他实现是否也这样做。总而言之，我们发现了十个实现存在此攻击的漏洞，因为它们允许单个参与者在不被检测到的情况下提高使用 Pedersen DKG 生成的共享密钥的阈值。（我们没有发现任何易受攻击的密钥共享方案实现。）

披露过程

我们于 2024 年 1 月 3 日联系了以下易受攻击的代码库的维护者：

• 由 Chelsea Komlo 维护的 Frost 的参考实现
• ZCash 基金会对 Frost 的实现
• Penumbra 在 decaf377 上对 Frost 的实现
• 由 Isis Lovecruft 维护的 Frost-Dalek
• Toposware 对 ICE-FROST 的实现
• Trust Machines 基于 Frost 对 WSTS 的实现
• 由 Jesse Possner 维护的 FROST-BIP340
• ZenGo-X 对 GG18 和 GG20 的实现
• Safeheron 对 GG20 的实现
• LatticeX 的 GG20 Open TSS 实现

七位维护者回复确认他们已收到披露。其中四位维护者（Chelsea Komlo、Jesse Possner、Safeheron 和 ZCash 基金会）还报告说，他们已经或计划解决此问题。

我们于 2024 年 2 月 7 日再次联系了三位未响应的维护者（Toposware、Trust Machines 和 LatticeX）。此后，Toposware 也回复确认他们已收到我们的披露。

We found cryptography bugs in the elliptic library using Wycheproof November 18, 2025\ Trail of Bits discovered and disclosed two vulnerabilities in the widely used elliptic JavaScript library that could …Vulnerabilities in LUKS2 disk encryption for confidential VMs October 30, 2025\ Trail of Bits is disclosing vulnerabilities in confidential computing systems that use LUKS2 for disk encryption. These …Keeping the wolves out of wolfSSL January 12, 2023\ Trail of Bits is publicly disclosing four vulnerabilities that affect wolfSSL: CVE-2022-38152, CVE-2022-38153, …

• 原文链接： blog.trailofbits.com/202...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～