天下漏洞,尽知其名
MEDIUM

CVE-2026-71891 Bouncy Castle Java 密钥验证绕过漏洞

影响攻击者可绕过公钥校验,伪造聚合签名中的幽灵签名者

MEDIUM
暂无 CVSS 评分
AI 研判

Bouncy Castle for Java 1.86 之前版本的 BLS12_381BasicScheme.keyValidate 在校验公钥时,仅依赖点自身所在曲线的 cofactor 判断是否属于素数阶子群,未确认曲线是否为规范的 BLS12-381 G1 曲线。攻击者可构造一条仅共享 BLS12-381 域特征、但方程与 cofactor 不同的外部曲线上的点,使其通过 keyValidate。在配对实现中该点对目标群贡献单位元,导致包含该公钥的聚合签名验证通过,即使其中并不存在对应密钥与消息的签名,从而引入幽灵签名者。

影响范围

Bouncy Castle Java

Bouncy Castle for Java 1.86 之前的版本,涉及 BLS12_381BasicScheme.keyValidate 及依赖它的 BLSPublicKeyParameters、BasicScheme、MessageAugmentation、ProofOfPossession 的 verify 与 aggregateVerify。

漏洞详情

漏洞类型为密钥/签名验证绕过。成因是 keyValidate 的素数阶子群检查信任点自身曲线的 cofactor,当曲线 cofactor 为 1 时 ECPoint.satisfiesOrder 直接返回 true,因此一条方程不同、cofactor 被伪造成 1 的外部曲线上的点也能通过校验,尽管它根本不是 G1 点。利用方式是构造此类非规范曲线上的 ECPoint 并作为权威公钥提交,在配对运算中该点贡献单位元,使聚合签名验证被接受,形成幽灵签名者。

利用条件与风险

利用前提是应用在显式非规范曲线上构造 ECPoint 并将其作为承载权威的公钥接受;标准用法下不可达,因此实际风险取决于具体集成方式,CVSS 评级为 MEDIUM。

修复建议

升级到 Bouncy Castle for Java 1.86 或更高版本,该版本在子群检查前先确认点所在曲线具有规范的 G1 域、方程、阶与 cofactor。临时缓解措施为暂无公开信息,建议避免接受来自非规范曲线的 ECPoint 作为公钥。

原始情报

In Bouncy Castle for Java before 1.86, BLS12_381BasicScheme.keyValidate, and so BLSPublicKeyParameters and every BasicScheme, MessageAugmentation and ProofOfPossession verify and aggregateVerify that gate on it, accepted a public key built on a foreign ECCurve that merely shares BLS12-381’s field characteristic. The prime-order subgroup check trusts a point’s own curve to name its cofactor, since ECPoint.satisfiesOrder returns true outright when the curve’s cofactor is one, so a point on a curve with a different equation and a cofactor forged to one passed keyValidate despite not being a G1 point at all. In BC’s pairing implementation such a point contributes the identity in the target group, so an aggregate signature verified against a set of public keys including it is accepted even though it contains no signature for that key and message pair, admitting a phantom signer. keyValidate now first confirms that the point’s curve carries exactly the canonical G1 field, equation, order and cofactor before any subgroup check. The issue is reachable only where an application constructs an ECPoint on an explicit, non-canonical curve and accepts it as an authority-bearing key; the standard 48-byte compressed-point decoder always supplies the canonical curve and was never affected.