Cryptographic Keys Management

Overview

This page contains recommendations for generating, storing and managing cryptographic keys.

Key generation

• Use cryptographically strong generators for generating cryptographic keys, see the Cryptography: Random Generators page.

• You can generate cryptographic keys with the key generation methods built into a library that implements cryptographic operations.

• The main criterion for choosing the key length and its lifetime is the required level of security, see the Cryptography: Encryption page.

• Encryption keys used to transfer other keys (for example, session keys) must have the same strength or higher.

• Do not base cryptographic keys on common words or phrases, or on "random" characters generated by mashing the keyboard.

• If you are using multiple keys (such as data separate data-encrypting and key-encrypting keys), generate these keys completely independently.

Key storage

• Store secret and private encryption keys in a secure vault, Trusted Platform Module (TPM) or Hardware Security Module (HSM) only.

• Do not store secret and private encryption keys next to encrypted data (for example, within a single database or on the disk).

• Do not hardcode secret and private encryption keys into config files or source code.

• Do not store secret and private encryption keys as environment variables.

• Do not push secret and private encryption keys into version control systems.

Key usage

• Do not use any production crypto-materials (nonces, initialization vectors, keys, etc.) in non-production (testing, staging, etc.) environments.

• Do not use one key to encrypt or sign all data. If there is an access control between objects and subjects, use different keys (for example, between different users, systems, or tenants).

• Use different keys for different cryptographic operations, such as encryption and signing.

Key rotation

• Implement a key decommission functionality to cover the following cases:

  • Key compromise (for example, leaking keys to the source code or having access from an employee who left an organization).

  • There is a significant change to the security provided by the algorithm (such as a new attack being announced).

• Implement encryption of existing data with newly generated keys during decommissioning. Use one of the following schemes:

  • Decrypt existing data and re-encrypting it with the new key.

  • Encrypt all data with the new key:

    • Decrypt data with the new and old keys on the first access after decommissioning.

    • Encrypt data only with the new key after the first access.

  • (Not preferred) Encrypt the data with the new key on the first access after decommissioning.

• Keep the old keys after decommissioning as long as the encrypted data is up to date (for example, if old backups need to be decrypted). You can determine the time period based on the required lifetime of the encrypted data, see the Cryptography: Encryption page.

• Implement periodic key rotation after a specified period of time has elapsed (known as the cryptoperiod), see the 5.3 Cryptoperiods section and the Table 1: Suggested cryptoperiods for key types table in NIST SP 800-57.