CVE-2026-71891

W Bouncy Castle dla Javy przed wersją 1.86 BLS12_381BasicScheme.keyValidate, a więc BLSPublicKeyParameters i każdy BasicScheme, MessageAugmentation i ProofOfPossession weryfikują i agregują tę bramę, akceptowają klucz publiczny zbudowany na obcym ECCurve, który jedynie ma wspólną charakterystykę pola BLS12-381. Sprawdzanie podgrupy rzędu pierwszego opiera się na własnej krzywej punktu w celu określenia jego kofaktora, ponieważ ECPoint.satisfiesOrder zwraca wartość true od razu, gdy kofaktorem krzywej jest jeden, a zatem punkt na krzywej z innym równaniem i kofaktorem skojarzonym z jednym przekazanym kluczemValidate, mimo że w ogóle nie jest punktem G1. W implementacji parowania BC taki punkt zapewnia tożsamość w grupie docelowej, więc podpis zbiorczy weryfikowany na podstawie zestawu kluczy publicznych, w tym klucza publicznego, jest akceptowany, nawet jeśli nie zawiera podpisu dla tej pary klucz-wiadomość, dopuszczając fantomowego podpisującego. keyValidate teraz najpierw potwierdza, że ​​krzywa punktu zawiera dokładnie kanoniczne pole G1, równanie, rząd i kofaktor przed jakimkolwiek sprawdzeniem podgrupy. Problem jest osiągalny tylko wtedy, gdy aplikacja konstruuje ECPoint na jawnej, niekanonicznej krzywej i akceptuje go jako klucz niosący uprawnienia; standardowy 48-bajtowy dekoder ze skompresowanym punktem zawsze dostarcza krzywą kanoniczną i nigdy nie miało to na niego wpływu.