En el Proveedor JCE de Bouncy Castle, la clave pública DH de la otra parte no se valida completamente

The core of this vulnerability lies in the insufficient validation of the DH public key received during key exchange. An attacker could craft a malicious public key that, when processed by the Bouncy Castle provider, would reveal details about the legitimate party's private key. This is particularly concerning in static Diffie-Hellman scenarios, where the same key pair is used repeatedly, increasing the window of opportunity for an attacker. While the impact isn't immediate remote code execution, the compromise of a private key can have far-reaching consequences, potentially enabling decryption of past communications and impersonation of the affected party. The risk is amplified in environments where Bouncy Castle is used for secure communication protocols like TLS/SSL.

Applications and systems relying on the Bouncy Castle JCE Provider for cryptographic operations, particularly those utilizing static Diffie-Hellman key exchange, are at risk. Legacy systems and applications that have not been updated regularly are especially vulnerable. Any environment where the confidentiality of private keys is critical is also at increased risk.

• java / application:

find / -name "bcprov-jdk14-*.jar" -mtime +30  # Find older JAR files

• java / application:

// Check Bouncy Castle version at runtime
java -jar your_application.jar -Dbc.version=$(java -Djava.security.properties=/path/to/java.security -cp bcprov-jdk14-1.55.jar org.bouncycastle.version.Version) 

• java / application: Monitor application logs for unusual key exchange errors or warnings related to DH parameters.

1. 2018-10-17Disclosure

   disclosure

1. Publicada2018-10-17
2. Modificada2025-09-12
3. EPSS actualizado2026-04-02

The primary mitigation for CVE-2016-1000346 is to upgrade to Bouncy Castle JCE Provider version 1.56 or later. This version includes the necessary key parameter checks to prevent the vulnerability. If an immediate upgrade is not feasible due to compatibility issues, consider implementing stricter key validation routines within your application code to supplement the provider's validation. While not a direct replacement, this can provide an additional layer of defense. Review your application's use of static Diffie-Hellman and consider migrating to more secure key exchange mechanisms where possible. After upgrading, confirm the fix by performing a key exchange test and verifying that the key parameters are correctly validated.