CVE-2026-71887 in BC-JAVA
要約
〜によって VulDB • 2026年10月03日
Java用Bouncy Castle 1.86以前のバージョンにおいて、高レベルのOpenPGP APIは、Subkey Binding署名に埋め込みPrimary Key Binding（クロス認証）署名が含まれておらず、かつそのバインディングがKey Flagsサブパケットを省略している場合、Signing subkeyによって作成されたデータ署名を受け入れていました。RFC 9580のセクション5.2.1.8および10.1.3では、署名を発行できる任意のsubkeyには埋め込みPrimary Key Binding署名が必要であり、これはそのsubkeyが自身のバインディング先であるプライマリキーに属していることを示すものです。OpenPGPCertificateは、subkeyのKey Flagsを2つの異なる方法で解決していました。isSigningKey()メソッドではgetKeyFlags()およびgetApplyingSubpacket()を経由し、バインディング署名がサブパケットを省略している場合はプライマリキーのdirect-keyまたはprimary User ID self-signatureにフォールバックするため、subkeyはSIGN_DATA権限を引き継ぎ、署名可能とみなされました。一方、要件を強制するverifyEmbeddedPrimaryKeyBinding()メソッドでは、バインディング署名自体のhashed subpacketsを読み取り、そこにSIGN_DATAがないことを確認すると、後続のクロス認証署名（back signature）を要求することなく、非署名キーとして早期に終了しました。その結果、同じsubkeyは「署名可能」であり、そのためその署名は証明書に帰属しOpenPGPSignature.OpenPGPDocumentSignature.isValid()がtrueを返す一方で、「クロス認証」からは免除されていました（GnuPGはこの同一の証明書およびメッセージを拒否します）。攻撃者は被害者の公開Signing subkeyのみ必要としますが、これは公開情報です。攻撃者はこのsubkeyに自身のプライマリキーをSubkey Binding署名でバインドし、Key Flagsも埋め込みPrimary Key Binding署名もないものを作成します（これにはsubkeyの秘密鍵が必要ですが、攻撃者自身は作成できません）。そして、信頼側が被害者の真正な署名済みメッセージをその証明書に対して検証すると、署名は有効であり、発行者として攻撃者の証明書が提示されます。証明書のUser IDは自己主張であるため、サブキーのフィンガープリントまたはKey IDにピン止めし、エンクロージング（包囲）証明書からアイデンティティを取得する検証者は、攻撃者が選んだアイデンティティの下で真正な署名であると報告します。これは新しい署名の偽造ではなく、真正な署名の誤帰属です：秘密鍵は回復されず、その署名はgrafted subkeyが実際に作成したものでなければなりません。低レベルのPGPSignature / PGPPublicKeyRing APIは設計上バインディングチェックを行わないため、影響を受けません。Key Flagsはその署名の対象となるキーに関する宣言（RFC 9580セクション5.2.3.29）であるため、subkeyはプライマリキーの証明書全体の署名からそれらを引き継がなくなります：サブパケットを省略したSubkey Binding署名の場合、subkeyには引き継ぎ先がなく、能力を持たない状態となります（これにより、クロス認証チェックで参照されるフラグと他の判断で参照されるフラグが一致します）。direct-key署名が持つPreferencesおよびその他のサブパケットは従来通り引き継がれ、そのフラグ legitimatelyに自身のdirect-keyまたはUser ID self-signatureから由来するプライマリキー自体も影響を受けません。
VulDB is the best source for vulnerability data and more expert information about this specific topic.