Red Hat Bugzilla – Bug 1563749
CVE-2018-5382 bouncycastle: BKS-V1 keystore files vulnerable to trivial hash collisions
Last modified: 2018-10-25 11:42:05 EDT
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
Statement: Red Hat Product Security has rated this issue as having security impact of Low. This issue is not currently planned to be addressed in future updates. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.
Note that per the cert advisory, bouncycastle 1.49 re-introduced the legacy signature format as an option, calling it "BKS-1". Version 1.49 and newer should avoid using this form for keystore verification.
This flaw affected BKS (Bouncy Castle keystore) version 1. It was fixed in Bouncy Castle version 1.47. However, as the fix implies a change to the keystore format, the new format is referred to as BKS version 2. The support for BKS version 1 was re-introduced again in Bouncy Castle version 1.49 (most likely because of backwards (in)compatibility concerns), however BKS version 2 remains the default. Applications using Bouncy Castle 1.49 or later may be affected if the explicitly request the use of BKS-V1 keystore format would still be affected by this issue. Relevant entries form the Bouncy Castle release notes: https://www.bouncycastle.org/releasenotes.html 1.47: The default MAC for a BKS key store was 2 bytes, this has been upgraded to 20 bytes. 1.49: A new KeyStore type, BKS-V1, has been added for people needing to create key stores compatible with earlier versions of Bouncy Castle.
This issue has been addressed in the following products: Red Hat Satellite 6.4 for RHEL 7 Via RHSA-2018:2927 https://access.redhat.com/errata/RHSA-2018:2927