Cryptographic Private Key

ID

private_key

Severity

critical

Vendor

-

Family

Crypto key

Description

Private keys are the secret part in an asymmetric (public-private) keypair. They are used in different contexts and cryptographic applications.

Most cryptography libraries use standard formats for private key exchange (like PEM )

Public Keys and Public Key Certificates are public and have no sensitivity or confidentiality requirements (but do not accept a public key without trust on the link between the key and its owner).

Security

Any private key, when leaked, is not a good thing: makes the operations relaying on it unsecure, and the impact goes from 'catastrophe' to 'Armageddon'.

The private key could be part of a TLS keypair with a digital certificate, and anyone with the private key can impersonate your servers, sniff the traffic, modify messages on transit…​

When the private key was used for code signing and other integrity, you may appear to be signing malware (!), and you may be the source of supply-chain attacks distributed to those poor guys that trusted your public-key signing certificate.

When a SSH key, depending on where the pairing public key was registered, bad guys may enter your internal or internet-facing hosts, make arbitrary commits to your software repositories 'protected' with SSH keys, exfiltrate sensitive laboratory data for ransom or benefit…​

In contrast with temporary access tokens, a leaked private key may have a big impact on the security and even on the organization’s business. Private keys should NEVER be committed to a software repository.

Examples

Imagine an RSA keypair where the private key is not encrypted with an protecting passphrase (or the private key is exported unprotected).

openssl genrsa -out private-key.pem 3072

If the (unprotected) private key file is accidentally disclosed:

-----BEGIN RSA PRIVATE KEY-----
MIIG5gIBAAKCAYEAsz2zBjNCZIZ5JEzfEW53cYEg+8+9QxjdD19S68cVmOUz3YIq
...
XwiXyHmHGcG4d3VxmAg/MNmiyZJJxHdWxjFgXpRCCwjXO9+Sn1kWWlAW
-----END RSA PRIVATE KEY-----

the detector will flag it.

Mitigation / Fix

  1. Remove private keys, in a file or hardcoded from the source code or committed configuration file.

  2. Follow your policy for handling leaked secrets, which typically require disabling the keypair and revoking the associated unexpired public key certificates, if any. This could be extremely difficult.

  3. If under a git repository, you may remove unwanted files from the repository history using tools like git filter-repo or BFG Repo-Cleaner. You may follow the procedure listed here for GitHub.

You should consider any sensitive data in commits with secrets as compromised.

Remember that secrets may be removed from history in your projects, but not in other users' cloned or forked repositories.

  1. Check usages of the private key to ensure that it was not used by unintended actors during the leakage window, which depends on the purpose of the private key.