Key Management - Learning Module

Loading content...

0/273

Key Rotation

Why Keys Must Change

Even the strongest cryptographic key becomes a liability over time. The longer a key remains in use, the more data it protects, the more opportunities for exposure, and the greater the damage if compromised. Key rotation—the systematic replacement of cryptographic keys—is how we bound this risk.

Consider a database encryption key used for three years without rotation. If compromised, an attacker gains access to three years of sensitive data. With monthly rotation, the same compromise exposes only one month. Key rotation transforms a potentially catastrophic breach into a contained incident.

This page explores the strategies, challenges, and automation patterns for key rotation that maintains security without disrupting operations.

What You Will Learn

By the end of this page, you will understand rotation triggers, strategies for different key types, handling the transition period, automating rotation, and managing the complexity of systems where old and new keys must coexist.

The Case for Key Rotation

Key rotation addresses multiple security concerns that compound over time:

Cryptanalytic risk accumulation: Every ciphertext encrypted with a key provides potential attack material. Advanced adversaries collect encrypted traffic for future analysis when computing power improves or new attacks emerge.

Exposure window limitation: Keys face constant exposure risks—memory dumps, side-channel attacks, insider threats, logging errors. Rotation ensures that any undetected exposure has a bounded impact.

Compliance requirements: Standards like PCI DSS mandate annual key rotation for encryption keys. NIST recommends rotation based on key usage volume and risk assessment.

Key Rotation Triggers and Frequencies
Trigger Type	Description	Typical Response
Time-based	Regular schedule (monthly, quarterly, annually)	Automatic rotation via KMS policies
Usage-based	After N encryptions or bytes encrypted	Counter-triggered rotation
Event-based	Personnel change, suspected breach	Immediate emergency rotation
Cryptographic	Algorithm weakness discovered	Migrate to new algorithm + rotate
Compliance	Audit finding or policy change	Scheduled rotation per requirements

Rotation ≠ Re-encryption

Key rotation creates a new key for future operations. It does NOT automatically re-encrypt existing data. Historical data remains encrypted with old keys, which must be retained (archived) until that data is re-encrypted or deleted.

Rotation Strategies by Key Type

Different key types require different rotation approaches based on their usage patterns and the systems that depend on them.

Rotation by Key Type

•Symmetric Data Keys (DEKs) — Rotate frequently (daily to monthly). Use envelope encryption so rotation only affects the wrapped DEK, not the KEK. New data uses new DEK; old data re-encrypted gradually or on access.
•Key Encryption Keys (KEKs) — Rotate less frequently (annually). When KEK rotates, all DEKs wrapped with old KEK must be re-wrapped with new KEK. Plan for bulk re-wrapping operations.
•TLS Certificates/Keys — Rotate with certificate renewal (90 days to 1 year). Automate with ACME/Let's Encrypt. Coordinate with load balancers and CDNs.
•API Keys/Tokens — Support multiple active keys during transition. Deprecate old keys with warnings before revocation. Provide clear migration windows.
•Signing Keys — Rotate signing keys while maintaining verification keys longer. Old signatures must remain verifiable. Version your signatures.

kms_automatic_rotation
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
import boto3
from datetime import datetime
 
class KMSKeyRotationManager:
    """Manage AWS KMS key rotation with automatic and manual options."""
    
    def __init__(self):
        self.kms = boto3.client('kms')
    
    def enable_automatic_rotation(self, key_id: str) -> dict:
        """
        Enable automatic annual rotation for a KMS key.
        AWS automatically creates new key material yearly.
        Old key material is preserved for decryption.
        """
        self.kms.enable_key_rotation(KeyId=key_id)
        
        status = self.kms.get_key_rotation_status(KeyId=key_id)
        return {
            'key_id': key_id,
            'rotation_enabled': status['KeyRotationEnabled'],
            'note': 'Key will rotate automatically every 365 days'
        }
    
    def manual_rotation_with_alias(self, alias_name: str) -> dict:
        """
        Manual rotation using alias pointing.
        1. Create new key
        2. Update alias to point to new key
        3. Applications using alias automatically use new key
        4. Old key retained for decryption of historical data
        """
        # Create new key
        new_key = self.kms.create_key(
            Description=f'Rotated key - {datetime.utcnow().isoformat()}',
            KeyUsage='ENCRYPT_DECRYPT',
            Origin='AWS_KMS'
        )
        new_key_id = new_key['KeyMetadata']['KeyId']
        
        # Get current key before rotation (for logging)
        try:
            old_alias = self.kms.describe_key(KeyId=alias_name)
            old_key_id = old_alias['KeyMetadata']['KeyId']
        except:
            old_key_id = None
        
        # Update alias to point to new key
        self.kms.update_alias(
            AliasName=alias_name,
            TargetKeyId=new_key_id
        )
        
        return {
            'alias': alias_name,
            'old_key_id': old_key_id,
            'new_key_id': new_key_id,
            'action': 'Archive old key after confirming no active encryptions'
        }

Managing the Transition Period

The most challenging aspect of key rotation is the transition period when both old and new keys must be active. Applications must:

Encrypt with new key: All new cryptographic operations use the rotated key
Decrypt with any key: Must handle data encrypted with current or any previous key
Identify key version: Ciphertext must indicate which key was used for decryption

Key versioning patterns:

Embedded Key ID

•Store key identifier with ciphertext
•Format: [key_id][nonce][ciphertext][tag]
•Decryption reads key_id first
•Fetches correct key for decryption
•Self-describing, portable ciphertext

Try-All-Keys

•Attempt decryption with newest key first
•On failure, try progressively older keys
•Works when key count is small
•No storage overhead for key ID
•Performance degrades with many keys

versioned_encryption
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
import struct
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os
 
class VersionedEncryption:
    """
    Encryption with embedded key version for seamless rotation.
    Ciphertext format: [version:4bytes][nonce:12bytes][ciphertext+tag]
    """
    
    def __init__(self):
        self.keys = {}  # version -> key bytes
        self.current_version = 0
    
    def add_key(self, version: int, key: bytes):
        """Register a key version."""
        self.keys[version] = key
        if version > self.current_version:
            self.current_version = version
    
    def encrypt(self, plaintext: bytes) -> bytes:
        """Encrypt using current key, embedding version."""
        key = self.keys[self.current_version]
        nonce = os.urandom(12)
        
        aesgcm = AESGCM(key)
        ciphertext = aesgcm.encrypt(nonce, plaintext, None)
        
        # Pack: version (4 bytes) + nonce (12 bytes) + ciphertext
        return struct.pack('>I', self.current_version) + nonce + ciphertext
    
    def decrypt(self, data: bytes) -> bytes:
        """Decrypt using embedded version to select key."""
        version = struct.unpack('>I', data[:4])[0]
        nonce = data[4:16]
        ciphertext = data[16:]
        
        if version not in self.keys:
            raise ValueError(f"Unknown key version: {version}")
        
        aesgcm = AESGCM(self.keys[version])
        return aesgcm.decrypt(nonce, ciphertext, None)
 
# Usage during rotation
crypto = VersionedEncryption()
crypto.add_key(1, os.urandom(32))  # Original key
crypto.add_key(2, os.urandom(32))  # Rotated key (becomes current)
 
# New encryptions use v2, old v1 ciphertexts still decrypt

Re-encryption Strategies

While key rotation creates new keys for future use, re-encryption migrates existing data to the new key. This is optional but recommended for high-security scenarios or when retiring old keys entirely.

Re-encryption approaches:

Re-encryption Strategy Comparison
Strategy	Approach	Pros	Cons
Lazy/On-Access	Re-encrypt when data is accessed	No bulk operation, gradual migration	Stale data never migrates, complex read path
Background Bulk	Batch job processes all encrypted data	Complete migration, can retire old keys	Resource intensive, may require downtime
Hybrid	Bulk for active data, lazy for cold data	Balances performance and completeness	More complex to implement
Envelope Re-wrap	Only re-encrypt DEKs, not data	Fast, data stays encrypted	Only works with envelope encryption

Envelope Encryption Advantage

With envelope encryption, rotating the KEK only requires re-wrapping the DEKs—not re-encrypting terabytes of data. A million DEKs can be re-wrapped in minutes. This is why envelope encryption is essential for large-scale systems.

Automation and Monitoring

Manual key rotation doesn't scale and introduces human error. Production systems require automated rotation with comprehensive monitoring.

Automation components:

Schedulers: Trigger rotation based on time or usage metrics
Orchestrators: Coordinate multi-system rotations (database, cache, queue)
Validators: Verify new keys work before committing rotation
Notifiers: Alert operations teams of rotation events
Rollback: Revert rotation if validation fails

rotation_automation
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
import boto3
from datetime import datetime, timedelta
 
class RotationOrchestrator:
    """Orchestrates key rotation across multiple systems."""
    
    def __init__(self, key_alias: str):
        self.kms = boto3.client('kms')
        self.key_alias = key_alias
        self.sns = boto3.client('sns')
    
    def execute_rotation(self, notification_topic: str) -> dict:
        """
        Complete rotation workflow with validation and notification.
        """
        rotation_id = datetime.utcnow().strftime('%Y%m%d%H%M%S')
        
        try:
            # 1. Create new key version
            new_key = self._create_rotated_key(rotation_id)
            
            # 2. Validate new key works
            self._validate_key(new_key['key_id'])
            
            # 3. Update alias to new key
            self._switch_alias(new_key['key_id'])
            
            # 4. Verify applications can encrypt/decrypt
            self._integration_test()
            
            # 5. Notify success
            self._notify(notification_topic, 'SUCCESS', rotation_id)
            
            return {'status': 'success', 'new_key': new_key['key_id']}
            
        except Exception as e:
            self._notify(notification_topic, 'FAILED', rotation_id, str(e))
            raise
    
    def _validate_key(self, key_id: str):
        """Test encrypt/decrypt cycle with new key."""
        test_data = b'rotation_validation_test'
        
        encrypted = self.kms.encrypt(KeyId=key_id, Plaintext=test_data)
        decrypted = self.kms.decrypt(
            CiphertextBlob=encrypted['CiphertextBlob']
        )
        
        if decrypted['Plaintext'] != test_data:
            raise ValueError("Key validation failed: decrypt mismatch")

Rotation Monitoring Metrics

•Key age: Days since last rotation (alert when approaching policy limit)
•Rotation success rate: Track failed rotations for investigation
•Legacy key usage: Monitor decryptions using old keys (should decrease over time)
•Re-encryption progress: Percentage of data migrated to new key
•Rotation duration: Time from start to completion (identify bottlenecks)

Summary: Key Rotation Best Practices

Key Takeaways

•Rotate proactively — Don't wait for compromise. Schedule rotation based on risk and compliance requirements.
•Use envelope encryption — KEK/DEK separation makes rotation fast by re-wrapping keys instead of re-encrypting data.
•Version your ciphertexts — Embed key identifiers so decryption always uses the correct key.
•Automate everything — Manual rotation is error-prone and doesn't scale. Use KMS automatic rotation where possible.
•Plan the transition — Old and new keys coexist during rotation. Test thoroughly before retiring old keys.
•Monitor and alert — Track key age, legacy usage, and rotation health metrics continuously.

Page Complete

You now understand key rotation strategies, transition management, and automation patterns. Next, we'll explore cloud KMS services (AWS KMS, GCP KMS) that provide managed rotation capabilities.