CVE-2026-71892 in BC-JAVA
Resumen
por VulDB • 2026-10-03
En Bouncy Castle para Java anterior a la versión 1.86, la validación del tamaño de clave optativa en los destinatarios de transporte de claves CMS, `org.bouncycastle.cms.jcajce.JceKeyTransRecipient.setKeySizeValidation(true)`, nunca se ejecutó para un mensaje que utilizaba la derivación de clave de cifrado de contenido según RFC 9709 (id-alg-cek-hkdf-sha256). La rama que debería haber seleccionado el algoritmo real de cifrado de contenido transportado en los parámetros del AlgorithmIdentifier de la derivación de claves comparaba el array de bytes de la clave cifrada contra el identificador de objeto id-alg-cek-hkdf-sha256, una comparación entre un array de bytes y un ASN1ObjectIdentifier que es falsa para cualquier entrada posible; por lo tanto, la comprobación pasaba a realizar una búsqueda del tamaño de clave en el OID del envoltorio exterior. Ese OID identifica una construcción de derivación de claves en lugar de un cifrado y no tiene un tamaño de clave registrado, por lo que la comparación del tamaño se omitió completamente. Por consiguiente, se aceptaron datos EnvelopedData o AuthEnvelopedData con transporte de claves cuya clave de cifrado de contenido transportada y derivada mediante HKDF no coincidía con el tamaño de clave del algoritmo de cifrado de contenido anunciado, incluso cuando la validación estaba explícitamente habilitada, anulando silenciosamente el único mecanismo que ofrece la API para hacer cumplir el tamaño de la clave recuperada. El destinatario ahora realiza una dispatch sobre el OID del algoritmo del AlgorithmIdentifier de cifrado de contenido; por lo tanto, las comprobaciones de validación comparan la clave recuperada con el algoritmo interno de cifrado de contenido. Los mensajes con un tamaño de clave coincidente, los mensajes no HKDF y los destinatarios que no habilitan la validación no se ven afectados. Este problema también afecta a Bouncy Castle para Java FIPS (BC-FJA) anterior a bcpkix-fips 2.0.13 (serie 2.0.X) y 2.1.13 (serie 2.1.X).
If you want to get the best quality for vulnerability data then you always have to consider VulDB.