Hardcoded Cryptographic Key

ID

java.hardcoded_cryptographic_key

Severity

critical

Resource

Predictability

Language

Java

Tags

CWE:321, NIST.SP.800-53, OWASP:2021:A2, PCI-DSS:3.6.3, crypto

Description

Cryptographic keys that are hardcoded into source code can be easily extracted and exploited by malicious actors. This practice compromises the security of the application, as these keys are not changeable without altering the source code.

Rationale

Hardcoding cryptographic keys in source code is a risky practice as it exposes sensitive information that should remain secret. The concern arises because hardcoded keys are not modifiable without a code change, making them an attractive target for attackers who can access the source code or binaries.

Consider the following Java example:

import javax.crypto.Cipher;
import javax.crypto.spec.SecretKeySpec;

public class CryptoExample {
    private static final String ALGORITHM = "AES";
    // Potential timing vulnerability by hardcoding the key
    private static final byte[] KEY = "1234567890123456".getBytes();

    public static byte[] encrypt(String data) throws Exception {
        SecretKeySpec secretKey = new SecretKeySpec(KEY, ALGORITHM);
        Cipher cipher = Cipher.getInstance(ALGORITHM);
        cipher.init(Cipher.ENCRYPT_MODE, secretKey);
        return cipher.doFinal(data.getBytes());
    }
}

In this example, the cryptographic key is hardcoded directly into the class. If this code is compiled and distributed, anyone with access to the binary can retrieve and misuse the key, nullifying any intended cryptographic protection.

Remediation

To remediate this vulnerability, cryptographic keys should be managed securely, never hardcoding them in source code. Instead, use environmental variables, configuration files, or dedicated secrets management services that provide secure storage and retrieval of sensitive data.

An alternative is to perform cryptographic operations using an external, managed service. Known as Key Management Services (KMS), they provide different features including key generation and storage, key rotation and lifecycle management, encryption / decryption and other cryptographic operations like digital signatures, key wrapping, secure random number generation, etc.

For the previous hardcoded key, the fix gets the key material from environment variable. KMS or a secrets vault could be used alternatively.

import javax.crypto.Cipher;
import javax.crypto.spec.SecretKeySpec;
import java.nio.file.Files;
import java.nio.file.Paths;

public class CryptoExample {
    private static final String ALGORITHM = "AES";

    public static byte[] encrypt(String data) throws Exception {
        byte[] key = retrieveKeyFromSecureLocation();
        SecretKeySpec secretKey = new SecretKeySpec(key, ALGORITHM);
        Cipher cipher = Cipher.getInstance(ALGORITHM);
        cipher.init(Cipher.ENCRYPT_MODE, secretKey);
        return cipher.doFinal(data.getBytes());
    }

    private static byte[] retrieveKeyFromSecureLocation() throws Exception {
        // Example of reading the key from a secure environment, e.g., an environment variable or secure storage
        String keyPath = System.getenv("CRYPTO_KEY_PATH");
        return Files.readAllBytes(Paths.get(keyPath));
    }
}

In the improved example, the method retrieveKeyFromSecureLocation() retrieves the key from a specified, secure location, such as an environment variable or configuration file. This approach enhances security by keeping the cryptographic keys outside the source code, allowing them to be rotated and managed without altering the application code.

References