CVE-2018-5382: Bouncy Castle BKS-V1 keystore files vulnerable to trivial hash collisions
Affected versions of the package are vulnerable to Hash Collision due to an error in the BKS version 1 keystore files.
BKS is a keystore format, designed to function similarly to a Sun/Oracle JKS keystore. BKS files can contain public keys, private keys and certificates, and they rely on a password-based encryption to provide confidentiality and integrity protections to the keystore contents.
The first version of a BKS file (aka BKS-V1) contained a design flaw when determining the key size used to protect the keystore data. It used the SHA-1 hash function, which is 160 bits in length. In a RFC7292-compliant cryptographic algorithm, the MAC key size should be the same size as the hash function being used, meaning that the MAC key size should be 160 bits long for BKS files.
However, Bouncy Castle BKS-V1 files uses only 16 bits for the MAC key size. Regardless of the complexity of the password, ghe BKS-V1 file will have merely 65,536 different encryption keys. An attacker may bruteforce this password in a matter of seconds by testing all 65K values.
References:
https://insights.sei.cmu.edu/cert/2018/03/the-curious-case-of-the-bouncy-castle-bks-passwords.html https://www.kb.cert.org/vuls/id/306792
Other sources
Bouncy Castle could allow a local attacker to obtain sensitive information, caused by an error in the BKS version 1 keystore files. By utilizing an HMAC that is only 16 bits long for the MAC key size, an attacker could exploit this vulnerability using brute-force techniques to crack a BKS-V1 keystore file in seconds and gain access to the keystore contents.
— IBM
The default BKS keystore use an HMAC that is only 16 bits long, which can allow an attacker to compromise the integrity of a BKS keystore. Bouncy Castle release 1.47 changes the BKS format to a format which uses a 160 bit HMAC instead. This applies to any BKS keystore generated prior to BC 1.47. For situations where people need to create the files for legacy reasons a specific keystore type "BKS-V1" was introduced in 1.49. It should be noted that the use of "BKS-V1" is discouraged by the library authors and should only be used where it is otherwise safe to do so, as in where the use of a 16 bit checksum for the file integrity check is not going to cause a security issue in itself.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
redhat/bouncycastleto a version that resolves this vulnerability.Fixed in 1.47 - Upgrade
Upgrade
Bouncy Castleto a version that resolves this vulnerability.Fixed in 1.47 - Upgrade
Upgrade
Bouncy Castleto a version that resolves this vulnerability.Fixed in 1.49 - Configuration
Do not use the legacy BKS-V1 keystore type unless legacy reasons require it, because it uses only a 16-bit MAC key size (making brute-force feasible).
Bouncy Castle (keystore format) keystore type = BKS-V1 (avoid)
Event History
Frequently Asked Questions
What is CVE-2018-5382?
CVE-2018-5382 is a vulnerability in Bouncy Castle that could allow a local attacker to obtain sensitive information.
What is the severity of CVE-2018-5382?
The severity of CVE-2018-5382 is medium with a CVSS score of 4.4.
How can an attacker exploit CVE-2018-5382?
An attacker can exploit CVE-2018-5382 by compromising the integrity of a BKS keystore that uses a 16-bit HMAC.
How do I fix CVE-2018-5382?
To fix CVE-2018-5382, update Bouncy Castle to version 1.47 or later.
Where can I find more information about CVE-2018-5382?
More information about CVE-2018-5382 can be found at the following links: [link1](https://insights.sei.cmu.edu/cert/2018/03/the-curious-case-of-the-bouncy-castle-bks-passwords.html), [link2](https://www.kb.cert.org/vuls/id/306792), [link3](https://access.redhat.com/security/updates/classification/).