Hash Collision Affecting org.bouncycastle:bcprov-jdk15on package, versions [,1.47)


0.0
critical

Snyk CVSS

    Attack Complexity Low
    Confidentiality High
    Integrity High
    Availability High

    Threat Intelligence

    EPSS 0.07% (30th percentile)
Expand this section
NVD
4.4 medium
Expand this section
Red Hat
5.1 medium

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk ID SNYK-JAVA-ORGBOUNCYCASTLE-31658
  • published 2 Apr 2018
  • disclosed 18 Mar 2018
  • credit Will Dormann

How to fix?

Upgrade org.bouncycastle:bcprov-jdk15on to version 1.47 or higher.

Overview

org.bouncycastle:bcprov-jdk15on is a Java implementation of cryptographic algorithms.

Affected versions of this package are vulnerable to Hash Collision. Hash Collision is possible within BKS 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.