๐Ÿ”‘ Cryptography

Cryptographic key management: the real weak point

Generating, storing, rotating and destroying cryptographic keys: the key life cycle, HSMs, envelope encryption and mistakes that defeat encryption.

Modern cryptographic algorithms are, in practice, unbreakable. Keys are not. A perfect AES-256 key is useless if it is written in a configuration file published by mistake, saved next to the data it is supposed to protect, or if its only copy sits on a failed disk. That is why security professionals often say that cryptography turns a data-protection problem into a key-management problem.

The life cycle of a key

A key goes through specific phases, each with its own risks.

1. Generation

The key must be produced by a cryptographically secure random number generator. A key derived from the time of day, a counter or a random function designed for video games can be guessed. If the key must be derived from a password, dedicated derivation functions are used, slow and salted.

2. Storage

This is the most delicate phase. The options, in increasing order of protection, are:

  • a file on disk, protected by permissions and preferably encrypted with a password;
  • dedicated system stores, such as the operating system's keychain;
  • key management services (KMS) offered by cloud platforms;
  • hardware security modules (HSMs), smart cards and tokens, from which the private key cannot be extracted.

With an HSM or a smart card, the application never sees the key: it sends the data to be encrypted or signed and receives the result. Even if the server is compromised, the attacker cannot walk away with the key; at most they can use it while they have access.

3. Distribution

Shared symmetric keys must be transmitted over protected channels, ideally through a key exchange or by encrypting them with a public key. Sending a password or key by email, in the same message as the encrypted file, cancels the protection.

4. Use

Each key should have a single purpose: one for encryption, one for signing, one per environment. Using the same key for different things creates unexpected interactions and, if it is compromised, multiplies the damage.

5. Rotation

Keys should be replaced periodically or after significant events, such as the departure of a colleague who had access. Rotation limits the amount of data exposed if a key is compromised and forces procedures to stay in working order.

6. Revocation and destruction

A compromised key must be revoked immediately and the people using it informed. A key that is no longer needed must be destroyed securely, along with its copies. But be careful: destroying a key means making the data encrypted with it unreadable forever. Sometimes that is exactly what you want, as in the "cryptographic erasure" of a disk.

Envelope encryption

A very common model, especially in the cloud, is envelope encryption:

  1. each file or record is encrypted with its own data key;
  2. the data key is encrypted with a master key, held in a KMS or HSM;
  3. only the encrypted data key is stored alongside the data.

To read a file, the application asks the KMS to decrypt the data key. This way the master key never leaves the protected module, access is logged and rotating the master key does not require re-encrypting all the data, only the data keys.

The most common mistakes

  • Keys in source code: API keys and passwords embedded in code end up in repositories, backups and sometimes public repositories. Once published, a key must be considered compromised even if the file is deleted, because it remains in the history.
  • Key next to the data: an encrypted backup saved in the same folder as the key file protects nothing.
  • No key backup: encryption works perfectly against the legitimate owner too. A lost key is lost data.
  • Too many people with access: every copy of a key and every person who knows it increases the risk.
  • No inventory: not knowing which keys exist, where they are and what they are for makes it impossible to rotate or revoke them during an incident.

A concrete example

A small professional practice decides to encrypt its backups. Sensible management might look like this:

Element Choice
Algorithm AES-256 in an authenticated mode, through reliable backup software
Key Generated by the software, protected by a long passphrase
Passphrase storage Password manager shared with only two people in charge
Emergency copy Printed and kept in a safe, outside the office
Rotation Whenever the people in charge change
Verification Periodic restore test using the emergency key

None of these steps requires advanced skills, but together they make the difference between real encryption and an illusion of it.

In short

  • The security of cryptography almost always depends on key management, not on the algorithm.
  • Every key has a life cycle: generation, storage, distribution, use, rotation, revocation and destruction.
  • HSMs, smart cards and KMS prevent the most important keys from being extracted.
  • Envelope encryption separates data keys from the master key and simplifies rotation.
  • Keys in code, keys without backups and keys stored next to the data are the most frequent mistakes.
MM
Marco Marzaduri

Marco Marzaduri works in cybersecurity, digital forensics and web development. A computer science graduate, he combines rigorous technical analysis with attention to the people who use technology.

Read also