CWE-321, Use of Hard-coded Cryptographic Key, covers products that use a hard-coded, unchangeable cryptographic key. The key lives in the code or firmware rather than in protected, replaceable storage.
Vendors of devices and software that ship to many customers are the main source. Teams that consume those products inherit the problem.
How it happens
A hard-coded key is convenient. It works the same on every machine and needs no setup. That convenience is the flaw. Every copy of the product carries the same key, and the key cannot be rotated without shipping new code.
// Vulnerable: same key in every deployment
private static final byte[] KEY = "0123456789abcdef".getBytes();
Cipher c = Cipher.getInstance("AES/GCM/NoPadding");
The observed examples are telling:
- CVE-2022-29960: an engineering workstation uses hard-coded cryptographic keys that could allow unauthorized filesystem access and privilege escalation.
- CVE-2022-30271: a remote terminal unit uses a hard-coded SSH private key that is likely to be used by default.
- CVE-2020-10884: a WiFi router service has a hard-coded encryption key, allowing root access.
- CVE-2014-2198: a communications product has a hardcoded SSH private key, allowing access to the root account.
What an attacker gains
MITRE says that if hard-coded keys are used, it is almost certain that malicious users will gain access through the account in question. The listed impacts are bypassing access control, gaining privileges or assuming identity, and reading application data.
Because the key is identical across installations, one extraction opens every deployment. Nobody needs to attack your system. They attack the product once.
How to find it
Static analysis can find some instances by looking for key sized literals and calls into crypto APIs with constant arguments. Secret scanning of repositories and build artifacts catches many more. For third party firmware or binaries, extract strings and look for PEM headers and long encoded blobs.
Try it yourself
This demo shows how secret scanning surfaces embedded credentials before they ship.
Click through it at your own pace, or open it full screen.
How to fix it
MITRE says prevention schemes mirror those for hard-coded password storage. In plain steps:
- Remove keys from source and firmware. Generate them per installation at first run or provisioning.
- Store keys in a secrets manager, hardware module or operating system keystore, not beside the code.
- Design for rotation. If replacing a key requires a new release, the design is wrong.
- Never reuse a default SSH key across devices. Generate a unique host key on each.
- Rotate any key that has already shipped, and assume it is public.
// Better: key supplied at runtime from a managed store
byte[] key = keyStore.getKey("app-data-key");
Quick check
Is a key safe if the source repository is private?
No. The key ships inside the compiled product, and anyone with the product can extract it.
Why is a per device key better?
Extracting one key then compromises one device, not all of them.
