Private Key

Image: Stern, Public domain, Wikimedia Commons

In short: The secret part of an asymmetric key pair — must absolutely stay secret for the whole scheme to be secure.

In more detail: The private key is used to decrypt data that was encrypted with the matching public key, or to create signatures that anyone can verify with the public key. A compromised private key (e.g. accidentally committed to a public Git repository) makes the entire key pair insecure — affected certificates then have to be revoked and reissued.

In Depth

A private key is typically stored as a PEM file and additionally protected with a passphrase:

-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gt...
-----END OPENSSH PRIVATE KEY-----

Two independent layers of protection come together here: first, the operating system’s file permissions (on Linux/macOS mandatorily chmod 600, so that only the owner themselves can even read the file at all), second a passphrase that additionally encrypts the file — even someone who steals the file can’t use it without the passphrase. Both layers of protection are independently useful: the file permission protects against other users of the same system, the passphrase additionally protects if the file somehow gets copied anyway (e.g. via a backup or a stolen laptop).

By far the most common real security incident around private keys is accidentally checking them into a public Git repository — automated scanners continuously search public repositories for exactly this pattern (the recognisable -----BEGIN ... PRIVATE KEY----- header) and often report finds to attackers within minutes. Once a private key is considered compromised, it must irrevocably be treated as insecure: the associated certificate has to be revoked and a completely new key pair generated — there’s no way to make a private key that’s once become public “private” again afterwards.

Hardware-based protection: when the key never leaves the device

The strongest form of protection for private keys goes beyond file permissions and passphrases: Hardware Security Modules (HSMs) and similar specialised chips (e.g. the Secure Enclave in Apple devices or a YubiKey) generate and store the private key DIRECTLY in special, tamper-resistant hardware — the key itself NEVER leaves this chip, not even for use. Instead of handing the key to software for signing/decryption, the software sends the data to be signed TO the chip, which performs the operation internally and returns only the result. Even if an attacker gains full access to the rest of the system, they can therefore never directly extract the private key this way — at most they can misuse the chip while they have physical access.

Key rotation as a proactive security measure

Even without concrete suspicion of compromise, regular key rotation (the planned, periodic replacement of keys even when no compromise is known) is considered good security practice, especially for server certificates and API keys in enterprise environments. The idea behind it: should a key have been compromised unnoticed (e.g. through a not-yet-discovered vulnerability), regular rotation limits the window of time in which an attacker can actually misuse the stolen key — similar to a regular password change (which today, however, is recommended less often than in the past for ordinary user passwords, for usability reasons, because it often leads users to pick weaker, easier-to-remember passwords).

Backup strategies for private keys

An often-overlooked dilemma: a private key must simultaneously be strictly secret AND protected against loss — if you lose the only private key (e.g. through a hard disk failure), data encrypted with it is irretrievably lost, without an attacker ever having been involved. For critical keys (e.g. the master key of an encryption infrastructure), “secret sharing” is therefore often used: the key is cryptographically split into several parts, distributed to different trusted people/locations, where only a minimum number of the parts (e.g. 3 of 5) can reconstruct the original key — this protects both against the loss of individual parts and against a single person alone having access to the complete key.

See also: Public key, Asymmetric encryption, Key