CVE-2026-71885
Beschrijving NL
In Bouncy Castle voor Java vóór 1.86 bindt de implementatie van Messaging Layer Security (MLS, RFC 9420) geen X.509-referentie aan de signature_key van een LeafNode. LeafNode.verify() controleerde de handtekening van een blad tegen de signature_key die in het blad zelf werd gedragen, terwijl de X.509-certificaatketen van de referentie werd opgeslagen maar nooit werd geparseerd of gevalideerd, dus de openbare sleutel van het eindentiteitscertificaat was nooit vereist om overeen te komen met signature_key zoals RFC 9420 sec. 5.3 vereist. Een partij kan daarom het certificaat van een andere partij als referentie presenteren tijdens het ondertekenen van het blad en het bijgevoegde KeyPackage, met een niet-gerelateerde sleutel, en worden geaccepteerd onder de identiteit van die andere partij via KeyPackage.verify () en het Group leaf-validation-pad. In een implementatie die externe commits toelaat zonder een onafhankelijke inlogcontrole, kan een niet-geverifieerde aanvaller worden toegelaten onder de X.509-identiteit van een slachtoffer, het slachtoffer uitzetten (hersynchronisatie vergelijkt hele inloggegevens in plaats van sleutels te ondertekenen), het huidige tijdperk afleiden, volgende groepsberichten decoderen en berichten verzenden die als slachtoffer worden geaccepteerd. TreeKEM.LeafNode vereist nu dat de openbare sleutel van het eindentiteitscertificaat, in de handtekeningcodering van de coderingssuite, gelijk is aan signature_key voor een X.509-referentie en verwerpt het blad anderszins, inclusief een lege keten of een certificaat waarvan het sleuteltype niet overeenkomt met de coderingssuite; certificaatketen en identiteitsvalidatie voor een vertrouwensanker blijven de verantwoordelijkheid van de applicatie volgens RFC 9420 sec. 5.3.1. Implementaties met alleen basisreferenties worden niet beïnvloed.
Origineel (Engels) tonen
In Bouncy Castle for Java before 1.86, the Messaging Layer Security (MLS, RFC 9420) implementation did not bind an X.509 credential to a LeafNode's signature_key. LeafNode.verify() checked a leaf's signature against the signature_key carried in the leaf itself, while the credential's X.509 certificate chain was stored but never parsed or validated, so the end-entity certificate's public key was never required to match signature_key as RFC 9420 sec. 5.3 requires. A party could therefore present another party's certificate as its credential while signing the leaf, and the enclosing KeyPackage, with an unrelated key, and be accepted under that other party's identity through KeyPackage.verify() and the Group leaf-validation path. In a deployment that admits external commits without an independent credential-admission check, an unauthenticated attacker could be admitted under a victim's X.509 identity, evict the victim (resynchronization compares whole credentials rather than signing keys), derive the current epoch, decrypt subsequent group messages, and send messages accepted as the victim. TreeKEM.LeafNode now requires the end-entity certificate's subject public key, in the cipher suite's signature encoding, to equal signature_key for an X.509 credential and rejects the leaf otherwise, including an empty chain or a certificate whose key type does not match the cipher suite; certificate-chain and identity validation to a trust anchor remain the application's responsibility per RFC 9420 sec. 5.3.1. Deployments using only basic credentials are unaffected.