CVE-2016-1000339 in JCE Provider
Summary
by MITRE
In the Bouncy Castle JCE Provider version 1.55 and earlier the primary engine class used for AES was AESFastEngine. Due to the highly table driven approach used in the algorithm it turns out that if the data channel on the CPU can be monitored the lookup table accesses are sufficient to leak information on the AES key being used. There was also a leak in AESEngine although it was substantially less. AESEngine has been modified to remove any signs of leakage (testing carried out on Intel X86-64) and is now the primary AES class for the BC JCE provider from 1.56. Use of AESFastEngine is now only recommended where otherwise deemed appropriate.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/13/2025
The vulnerability identified as CVE-2016-1000339 represents a critical side-channel attack vector within the Bouncy Castle Java Cryptography Extension provider implementation. This flaw specifically affects versions 1.55 and earlier of the cryptographic library, where the AES encryption implementation suffers from cache timing attacks that can potentially reveal sensitive cryptographic key information. The vulnerability stems from the implementation's reliance on table-driven approaches in the AES algorithm, particularly within the AESFastEngine class which was the primary engine for AES operations in these older versions.
The technical exploitation of this vulnerability occurs through monitoring data channel accesses on the CPU, specifically targeting the lookup table operations that are inherent to the AES algorithm implementation. The AESFastEngine's highly table-driven approach creates predictable memory access patterns that can be observed through cache timing analysis, allowing attackers to infer information about the encryption key being processed. This type of attack falls under the category of cache timing side-channel attacks, which are particularly dangerous because they can be executed remotely without requiring physical access to the target system. The vulnerability is classified as CWE-310 in the Common Weakness Enumeration framework, specifically relating to cryptographic weaknesses that arise from implementation flaws rather than algorithmic issues.
The operational impact of this vulnerability extends beyond simple information disclosure, as it can potentially lead to complete cryptographic key recovery under certain conditions. The attack requires sophisticated monitoring capabilities to observe the timing variations in memory access patterns, but the relatively straightforward nature of the implementation flaw means that such attacks are not overly complex to execute. The security implications are particularly severe in environments where the Bouncy Castle provider is used for sensitive cryptographic operations, as the leakage could compromise the confidentiality of encrypted data. The vulnerability affects systems running on Intel X86-64 architectures, though similar issues could potentially exist on other platforms with cache-based memory access patterns.
The Bouncy Castle development team addressed this vulnerability by modifying the AESEngine implementation to eliminate the timing leakage while maintaining cryptographic security. This fix involved redesigning the algorithm implementation to remove any predictable access patterns that could be exploited through cache monitoring. The updated implementation ensures that memory access patterns remain constant regardless of the input data or key material, effectively neutralizing the side-channel attack vector. The solution represents a fundamental change in how the AES algorithm is implemented within the cryptographic provider, moving away from the table-driven approach that was vulnerable to a more constant-time implementation. This change aligns with the ATT&CK framework's defensive techniques for mitigating side-channel attacks by ensuring that implementation details do not inadvertently reveal cryptographic information through timing variations. The recommendation to use AESEngine as the primary AES class from version 1.56 onward represents a complete remediation strategy that addresses the root cause rather than implementing workarounds. Organizations using affected versions should immediately upgrade to version 1.56 or later to eliminate this vulnerability, as the AESFastEngine class is no longer recommended for use due to its continued susceptibility to similar timing attacks. The fix demonstrates the importance of considering side-channel attack vectors during cryptographic implementation and highlights the ongoing need for security reviews of cryptographic libraries to identify and address implementation flaws that could compromise system security.