In Bouncy Castle JCE Provider wird der DH-öffentliche Schlüssel der Gegenpartei nicht vollständig validiert

The core impact of CVE-2016-1000346 lies in the potential for an attacker to gain information about the private key used in a static Diffie-Hellman key exchange. This could allow an attacker to decrypt previously intercepted communications or impersonate legitimate parties. While the CVSS score is LOW, the potential for key compromise, particularly in systems relying on static DH for long-term security, warrants immediate attention. The vulnerability doesn't directly enable remote code execution, but the compromise of cryptographic keys can have far-reaching consequences, potentially leading to data breaches and system compromise. Static Diffie-Hellman is often used in embedded systems and legacy applications, making these deployments particularly vulnerable.

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. Veröffentlicht2018-10-17
2. Geändert2025-09-12
3. EPSS aktualisiert2026-04-02

The primary mitigation for CVE-2016-1000346 is to upgrade to Bouncy Castle JCE Provider version 1.56 or later, which includes the necessary key validation checks. If an immediate upgrade is not feasible due to compatibility issues or system downtime constraints, consider implementing stricter key management practices and monitoring for suspicious activity related to key exchanges. While a WAF or proxy cannot directly address this vulnerability, they can be configured to detect and block unusual traffic patterns associated with key compromise attempts. There are no specific Sigma or YARA rules readily available for this vulnerability, as it primarily involves cryptographic protocol behavior.