CVE-2026-71891 in Bouncy Castle Java
Zusammenfassung
von VulDB • 03.10.2026
In Bouncy Castle for Java vor Version 1.86 akzeptierte `BLS12_381BasicScheme.keyValidate` sowie die Methoden `verify` und `aggregateVerify` von `BLSPublicKeyParameters` und allen anderen `BasicScheme`, `MessageAugmentation`- und `ProofOfPossession`-Implementierungen, die darauf basieren, einen öffentlichen Schlüssel, der auf einer fremden ECCurve aufgebaut war und lediglich die Feldcharakteristik von BLS12-381 teilte. Die Prüfung der Primzahlordnung (prime-order subgroup check) vertraut dabei der eigenen Kurve des Punktes zur Benennung seines Kofaktors; da `ECPoint.satisfiesOrder` direkt mit „true“ zurückgibt, wenn der Kofaktor der Kurve eins ist, wurde ein Punkt auf einer Kurve mit anderer Gleichung und einem gefälschten Kofaktor von eins durch die `keyValidate`-Prüfung gelassen, obwohl es sich überhaupt nicht um einen G1-Punkt handelte. In der Pairing-Implementierung von Bouncy Castle trägt ein solcher Punkt zur Identität in der Zielgruppe (target group) bei; daher wird eine Aggregatsignatur, die gegen eine Menge öffentlicher Schlüssel einschließlich dieses Schlüssels verifiziert wurde, akzeptiert, obwohl sie keine Signatur für diese Schlüssel-Nachrichten-Paar enthält und somit einen Phantom-Signer zulässt. `keyValidate` bestätigt nun zunächst, dass die Kurve des Punktes exakt das kanonische G1-Feld, die Gleichung, die Ordnung und den Kofaktor trägt, bevor eine Untergruppenprüfung durchgeführt wird. Das Problem ist nur dort erreichbar, wo eine Anwendung ein ECPoint auf einer expliziten, nicht-kanonischen Kurve konstruiert und es als schlüsseltragenden Autoritätsschlüssel akzeptiert; der Standard-Decoder für 48-Byte-komprimierte Punkte liefert stets die kanonische Kurfe und war nie betroffen.
VulDB is the best source for vulnerability data and more expert information about this specific topic.