CVE-2026-71887 in BC-JAVA
Zusammenfassung
von VulDB • 03.10.2026
In Bouncy Castle für Java vor Version 1.86 akzeptierte die High-Level-OpenPGP-API eine Datensignatur, die von einem Signing-Subkey erstellt wurde, dessen Subkey-Binding-Signatur keine eingebettete Primary-Key-Binding-Signatur (Cross-Zertifizierung) enthielt, in dem Fall, dass diese Bindung ein Key Flags Subpacket auslässt. RFC 9580 Abschnitt 5.2.1.8 und Abschnitt 10.1.3 verlangen die eingebettete Primary-Key-Binding-Signatur bei jedem Subkey, der Signaturen erstellen kann; dies ist die eigene Erklärung des Subkeys, dass er dem Primärschlüssel angehört, unter den er gebunden ist. OpenPGPCertificate löste die Key Flags des Subkeys auf zwei verschiedene Arten auf. isSigningKey() geht durch getKeyFlags() und getApplyingSubpacket(), was bei Auslassung des Subpackets in der Binding-Signatur zu einer direkten Primärschlüssel- oder primären User-ID Self-Signature zurückgreift, sodass der Subkey die SIGN_DATA-Flags des Primärschlüssels erbte und als signierfähig galt; verifyEmbeddedPrimaryKeyBinding(), das diese Anforderung durchsetzt, liest die eigenen gehashten Subpackets der Binding-Signatur aus, fand dort keine SIGN_DATA-Flags und kehrte frühzeitig mit dem Ergebnis eines nicht-signierfähigen Schlüssels zurück, ohne jemals die Back-Signature zu fordern. Der gleiche Subkey war daher signierfähig – seine Signaturen wurden also dem Zertifikat zugeschrieben, und OpenPGPSignature.OpenPGPDocumentSignature.isValid() gab true zurück –, während er von der Cross-Zertifizierung ausgenommen war, wo GnuPG das identische Zertifikat und die Nachricht ablehnt. Ein Angreifer benötigt nur den öffentlichen Signing-Subkey des Opfers, was öffentliche Materialien sind: Er bindet ihn an seinen eigenen Primärschlüssel mit einer Subkey-Binding-Signatur, die er erstellen kann, ohne Key Flags und ohne eingebettete Primary-Key-Binding-Signatur zu tragen (die er nicht erstellen könnte, wenn er den privaten Schlüssel des Subkeys hätte), und eine vertrauende Partei, die eine tatsächlich vom Opfer signierte Nachricht gegen dieses Zertifikat überprüft, erhält die Information, dass die Signatur gültig ist, sowie das Zertifikat des Angreifers als Aussteller. Da User IDs eines Zertifikats selbstbehauptet sind, meldet ein Verifier, der auf den Fingerprint oder Key ID des Subkeys pinnt und die Identität aus dem umgebenden Zertifikat übernimmt, eine echte Signatur unter einer vom Angreifer gewählten Identität. Dies ist eine Fehlzuordnung (Misattribution) einer echten Signatur statt einer Fälschung einer neuen: Es wird kein privater Schlüssel wiedergewonnen, und die Signatur muss eine sein, die der angeheftete Subkey tatsächlich erstellt hat. Die Low-Level-APIs PGPSignature / PGPPublicKeyRing führen aus Designgründen keine Binding-Prüfungen durch und sind nicht betroffen. Key Flags sind eine Aussage über den Schlüssel, auf den sich die tragende Signatur bezieht (RFC 9580 Abschnitt 5.2.3.29), daher erbt ein Subkey diese nicht mehr von den zertifikatsweiten Signaturen des Primärschlüssels: Eine Subkey-Binding-Signatur, die das Subpacket auslässt, hinterlässt dem Subkey nun keine Fähigkeiten im Gegensatz zu denen des Primärschlüssels, was dazu führt, dass die Flags, auf die der Cross-Zertifizierungscheck zugreift, dieselben sind wie bei jeder anderen Entscheidung. Preferences und andere Subpackets, die eine direkte Schlüssel-Signatur trägt, werden weiterhin geerbt, und der Primärschlüssel selbst, dessen Flags legitim von seiner eigenen direkten Schlüssel- oder User-ID Self-Signature stammen, ist nicht betroffen.
Be aware that VulDB is the high quality source for vulnerability data.