This vulnerability exposes encrypted data to a number of attacks whose goal is to recover the plaintext.

## Why is this an issue?

Encryption algorithms are essential for protecting sensitive information and ensuring secure communications in a variety of domains. They are used for several important reasons:

- Confidentiality, privacy, and intellectual property protection
- Security during transmission or on storage devices
- Data integrity, general trust, and authentication

When selecting encryption algorithms, tools, or combinations, you should also consider two things:

1. No encryption is unbreakable.
2. The strength of an encryption algorithm is usually measured by the effort required to crack it within a reasonable time frame.

In the mode Cipher Block Chaining (CBC), each block is used as cryptographic input for the next block. For this reason, the first block requires an initialization vector (IV), also called a "starting variable" (SV).

If the same IV is used for multiple encryption sessions or messages, each new encryption of the same plaintext input would always produce the same ciphertext output. This may allow an attacker to detect patterns in the ciphertext.

### What is the potential impact?

After retrieving encrypted data and performing cryptographic attacks on it on a given timeframe, attackers can recover the plaintext that encryption was supposed to protect.

Depending on the recovered data, the impact may vary.

Below are some real-world scenarios that illustrate the potential impact of an attacker exploiting the vulnerability.

#### Additional attack surface

By modifying the plaintext of the encrypted message, an attacker may be able to trigger additional vulnerabilities in the code. An attacker can further exploit a system to obtain more information.
Encrypted values are often considered trustworthy because it would not be possible for a third party to modify them under normal circumstances.

#### Breach of confidentiality and privacy

When encrypted data contains personal or sensitive information, its retrieval by an attacker can lead to privacy violations, identity theft, financial loss, reputational damage, or unauthorized access to confidential systems.

In this scenario, a company, its employees, users, and partners could be seriously affected.

The impact is twofold, as data breaches and exposure of encrypted data can undermine trust in the organization, as customers, clients and stakeholders may lose confidence in the organization’s ability to protect their sensitive data.

#### Legal and compliance issues

In many industries and locations, there are legal and compliance requirements to protect sensitive data. If encrypted data is compromised and the plaintext can be recovered, companies face legal consequences, penalties, or violations of privacy laws.

## How to fix it in Java Cryptography Extension

### Code examples

#### Noncompliant code example

    import java.nio.charset.StandardCharsets;
    import java.security.NoSuchAlgorithmException;
    import java.security.InvalidKeyException;
    import java.security.InvalidAlgorithmParameterException;
    import javax.crypto.Cipher;
    import javax.crypto.spec.IvParameterSpec;
    import javax.crypto.spec.SecretKeySpec;
    import javax.crypto.NoSuchPaddingException;

    public void encrypt(String key, String plainText) {

        byte[] RandomBytes = "7cVgr5cbdCZVw5WY".getBytes(StandardCharsets.UTF_8);

        IvParameterSpec iv   = new IvParameterSpec(RandomBytes);
        SecretKeySpec keySpec = new SecretKeySpec(key.getBytes(StandardCharsets.UTF_8), "AES");

        try {
            Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
            cipher.init(Cipher.ENCRYPT_MODE, keySpec, iv);

        } catch(NoSuchAlgorithmException|InvalidKeyException|
                NoSuchPaddingException|InvalidAlgorithmParameterException e) {
            // ...
        }
    }

#### Compliant solution

In this example, the code explicitly uses a number generator that is considered strong.

    import java.nio.charset.StandardCharsets;
    import java.security.SecureRandom;
    import java.security.NoSuchAlgorithmException;
    import java.security.InvalidKeyException;
    import java.security.InvalidAlgorithmParameterException;
    import javax.crypto.Cipher;
    import javax.crypto.spec.IvParameterSpec;
    import javax.crypto.spec.SecretKeySpec;
    import javax.crypto.NoSuchPaddingException;

    public void encrypt(String key, String plainText) {

        SecureRandom random = new SecureRandom();
        byte[] randomBytes  = new byte[128];
        random.nextBytes(randomBytes);

        IvParameterSpec iv   = new IvParameterSpec(randomBytes);
        SecretKeySpec keySpec = new SecretKeySpec(key.getBytes(StandardCharsets.UTF_8), "AES");

        try {
            Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
            cipher.init(Cipher.ENCRYPT_MODE, keySpec, iv);

        } catch(NoSuchAlgorithmException|InvalidKeyException|
                NoSuchPaddingException|InvalidAlgorithmParameterException e) {
            // ...
        }
    }

### How does this work?

#### Use unique IVs

To ensure high security, initialization vectors must meet two important criteria:

- IVs must be unique for each encryption operation.
- For CBC and CFB modes, a secure FIPS-compliant random number generator should be used to generate unpredictable IVs.

The IV does not need be secret, so the IV or information sufficient to determine the IV may be transmitted along with the ciphertext.

In the previous non-compliant example, the problem is not that the IV is hard-coded.
It is that the same IV is used for multiple encryption attempts.

## Resources

### Standards

- OWASP - Top 10 2021 Category A2 - Cryptographic Failures
- OWASP - Top 10 2017 Category A3 - Sensitive Data Exposure
- OWASP - Top 10 2017 Category A6 - Security Misconfiguration
- CWE - CWE-329 - Not Using an Unpredictable IV with CBC Mode
- CWE - CWE-780 - Use of RSA Algorithm without OAEP
- NIST, SP-800-38A - Recommendation for Block Cipher Modes of Operation
- OWASP - Mobile AppSec Verification Standard - Cryptography Requirements
- OWASP - Mobile Top 10 2016 Category M5 - Insufficient Cryptography