Cryptographic Key Management Security Pattern

When integrating cryptographic primitives into a system, correctly managing cryptographic keys is a crucial aspect. This pattern encapsulates common issues when applying solutions involving cryptography.

Importance

Proper key management is one of the most crucial aspects when applying cryptography.

Any security guarantees provided by a cryptosystem can be nullified if an attacker can obtain or tamper with the used cryptographic key(s).

Example: An attacker that obtains a supposedly secret session key will be able to decrypt all messages encrypted with that key.

Key Security Requirements

In most circumstances, cryptographic keys should be:

1. Kept confidential throughout their lifecycle
2. Have their integrity protected throughout their lifecycle

Exception: For some types of keys, such as the public key in an asymmetric key pair, the confidentiality requirement can be relaxed (but integrity must still be protected).

Core Components

Role	Type	Responsibility
Entity	Entity	Wants to generate and use cryptographic keys
Cryptographer	Cryptographic Primitive	Library generating keys and performing cryptographic actions

Data Elements

• keyConf: Configuration for key generation (e.g., symmetric/asymmetric, key length) - optional
• keyInfo: Information on the key to use (identifier or key material itself, depending on implementation)
• input: Plaintext input for cryptographic action
• output: Result of cryptographic action (e.g., ciphertext, signature)
• config: Configuration for Cryptographer (e.g., cipher mode) - optional

Actions

• generate_key: Generate new cryptographic key according to configuration
• crypto_action: Perform cryptographic action (e.g., encrypt, sign) using identified key

Pattern Flow

Key Generation

Entity → [generate_key(keyConf)] → Cryptographer
Cryptographer → [keyInfo] → Entity

The Entity requests key generation with optional configuration. The Cryptographer generates the key and returns information needed to use it in future requests.

Cryptographic Action

Entity → [crypto_action(input, keyInfo, config)] → Cryptographer
Cryptographer → [output] → Entity

To use a previously generated key, Entity provides keyInfo received during generation along with input data and optional configuration.

Security Considerations

Key Configuration Protection (keyConf)

If key configuration is provided, it should be protected from undetected tampering:

• During transmission over uncontrolled channels
• During persistent storage by Entity

Risk Example: An attacker may change key configuration to generate a shorter key than advised, making ciphertexts easier to break.

Key Information Protection (keyInfo)

After generating a key, Entity receives keyInfo which it will process and use in further interactions.

• Protect against unauthorized tampering during transmission and storage
• An attacker that can influence keyInfo might change the key used to one under their control
• Example: Attacker tampers with keyInfo so encryption uses a key the attacker knows, allowing decryption

The exact information and necessary security measures depend on the chosen implementation pattern.

Configuration Protection (config)

If Entity provides action configuration to Cryptographer:

• Protect against undetected tampering during transmission and storage
• Attacker might change config to use insecure, deprecated ciphers

Implementation Patterns

This pattern has two main implementations:

1. Cryptography as a Service

• Delegate key management to external service (e.g., KMS, HSM)
• System never possesses cryptographic keys directly
• Only stores key identifiers
• Reduces risk of key leakage
• Examples: AWS KMS, Azure Key Vault, Google Cloud KMS, Android Keystore

2. Self-Managed Cryptography

• Application manages keys itself
• Application responsible for key storage, distribution, revocation
• Requires careful attention to key confidentiality and integrity
• More control but more responsibility

Key Lifecycle Considerations

Throughout a key's lifecycle, ensure:

Phase	Confidentiality	Integrity
Generation	Protect output	Protect configuration
Storage	Encrypt at rest	Detect tampering
Distribution	Secure channel	Verify authenticity
Usage	Limit exposure	Validate before use
Rotation	Secure transition	Complete replacement
Destruction	Secure deletion	Confirm destruction

Symmetric vs. Asymmetric Keys

Key Type	Confidentiality	Integrity
Symmetric key	Required	Required
Asymmetric private key	Required	Required
Asymmetric public key	Can be relaxed	Required

Note: Even public keys require integrity protection—an attacker substituting a public key can compromise the entire system.

Implementation Checklist

• [ ] Key confidentiality protected (storage and transmission)
• [ ] Key integrity protected (storage and transmission)
• [ ] Key configuration protected from tampering
• [ ] KeyInfo protected from tampering
• [ ] Action configuration protected from tampering
• [ ] Key lifecycle managed (generation through destruction)
• [ ] Appropriate implementation chosen (as-a-service vs. self-managed)
• [ ] Public key integrity verified even if confidentiality relaxed

Related Patterns

• Cryptographic action (uses keys managed by this pattern)
• Encryption (specific cryptographic action)
• Digital signature (specific cryptographic action)
• Message authentication code (specific cryptographic action)
• Cryptography as a service (implementation pattern)
• Self-managed cryptography (implementation pattern)

References

• Source: https://securitypatterns.distrinet-research.be/patterns/99_02_001__crypto_key_management/
• E. Barker, 'Recommendation for Key Management: Part 1 – General', NIST SP 800-57 Part 1, May 2020
• NIST SP 800-130, 'A Framework for Designing Cryptographic Key Management Systems'
• OWASP Key Management Cheat Sheet