CVE-2026-71891: BLS12-381 в Bouncy Castle принимает публичный ключ с чужой кривой
В Bouncy Castle для Java до версии 1.86 механизм проверки ключей BLS12-381 принимал публичный ключ, построенный на посторонней эллиптической кривой. Это позволяет сформировать «фантомного подписанта» и провести агрегированную подпись без реального ключа и сообщения. Уязвимость оценена как HIGH (CVSS 7.1).
Подробности
Уязвимости подвержены версии Bouncy Castle for Java до 1.86. Речь идёт о методе BLS12_381BasicScheme.keyValidate, а вместе с ним — о BLSPublicKeyParameters и всех схемах BasicScheme, MessageAugmentation и ProofOfPossession, а также об операциях verify и aggregateVerify, которые опираются на эту проверку. Суть проблемы в том, что keyValidate принимал публичный ключ, построенный на посторонней кривой ECCurve, которая лишь разделяет характеристику поля с BLS12-381. Проверка подгруппы простого порядка доверяла самой точке в вопросе её кофактора: метод ECPoint.satisfiesOrder возвращает true сразу, если кофактор кривой равен единице. В результате точка на кривой с другим уравнением и подделанным кофактором, равным единице, проходила keyValidate, хотя вовсе не являлась точкой группы G1. В реализации спаривания Bouncy Castle такая точка вносит единичный элемент в целевую группу. Поэтому агрегированная подпись, проверяемая против набора публичных ключей, включающего такую точку, принимается, даже если в ней нет подписи для соответствующей пары «ключ — сообщение». Это открывает возможность для так называемого фантомного подписанта. Проблеме присвоен уровень CVSS 7.1 (HIGH). Важно отметить условия эксплуатации: уязвимость достижима только там, где приложение само конструирует ECPoint на явно заданной, неканонической кривой и принимает его как ключ, наделённый полномочиями. Стандартный 48-байтовый декодер сжатых точек всегда подставляет каноническую кривую и никогда не был затронут.Что делать
Основная рекомендация — обновить Bouncy Castle for Java до версии 1.86 или более поздней. В этой версии keyValidate сначала подтверждает, что кривая точки несёт ровно канонические поле G1, уравнение, порядок и кофактор, и только после этого выполняет проверку подгруппы. Если обновление невозможно, следует ограничить приём публичных ключей только через стандартный декодер сжатых точек и исключить любую логику, при которой ECPoint строится на явно заданной неканонической кривой и принимается как доверенный ключ. Также стоит проверить приложения, использующие агрегированные подписи BLS, на предмет подобных сценариев конструирования ключей. Итог: уязвимость позволяет обойти проверку публичных ключей BLS12-381 и провести агрегированную подпись с фантомным подписантом, но требует нестандартного способа формирования ключа на стороне приложения. Обновление до 1.86 закрывает проблему полностью, а до его установки помогает отказ от приёма ключей, построенных на неканонических кривых.Источник: CVE Project (cvelistV5)
