Operating SystemsSecurity Fundamentals

Cryptography Basics

LevelIntermediate

Duration90 mins

TopicSecurity Fundamentals

5 / 5

Key Management

Where Cryptography Meets Reality

The most secure encryption algorithm in the world is worthless if its keys are mishandled. AES-256 provides theoretically unbreakable encryption, but if the key is stored in plaintext in a configuration file, posted in a Git repository, or generated from a predictable source, the security collapses entirely.

Key management is where cryptographic theory meets operational reality. It encompasses every aspect of handling cryptographic keys throughout their lifecycle:

Generation: Creating keys with sufficient randomness
Storage: Protecting keys at rest from unauthorized access
Distribution: Delivering keys securely to authorized parties
Usage: Controlling and auditing how keys are used
Rotation: Replacing keys before they're compromised or expire
Destruction: Securely erasing keys when no longer needed

History shows that cryptographic failures almost always stem from key management weaknesses, not algorithm flaws. The Debian OpenSSL vulnerability (2008) produced predictable keys due to a broken random number generator. The Target breach (2013) originated from stolen credentials (keys). The countless "exposed AWS keys" incidents result from keys committed to source control. Understanding key management is essential for building systems that are secure not just in theory, but in practice.

What You Will Learn

By the end of this page, you will understand the key lifecycle and its security implications, master key generation and entropy requirements, comprehend key storage options from software to HSMs, recognize key derivation functions and their applications, understand how operating systems manage cryptographic keys, and apply best practices for key rotation and secure destruction.

The Key Lifecycle

Every cryptographic key passes through distinct phases, each with specific security requirements and potential vulnerabilities.

Phase 1: Generation

Keys must be generated with sufficient entropy (randomness). A 256-bit key that can be predicted or has patterns provides far less than 256 bits of security. Proper key generation requires:

Cryptographically secure random number generator (CSPRNG)
Sufficient entropy source (hardware RNG, environmental noise)
Verification that key meets algorithm requirements

Phase 2: Storage

Keys at rest must be protected from unauthorized access. Storage options range from software keystores (encrypted files) to Hardware Security Modules (HSMs). The storage mechanism must protect against:

Unauthorized reads (access control, encryption)
Memory inspection (secure memory allocation)
Persistence in deleted files (secure erasure)

Phase 3: Distribution

Keys must reach authorized parties without interception. Methods include:

Key agreement protocols (Diffie-Hellman)
Key encapsulation (encrypted key transport)
Out-of-band delivery (separate secure channel)
Key derivation (derive from shared master secret)

Key Lifecycle Phases and Security Considerations
Phase	Primary Threat	Protection Mechanism	Failure Example
Generation	Weak randomness	Hardware RNG, proper CSPRNG	Debian OpenSSL (predictable keys)
Storage	Unauthorized access	Encryption, HSMs, access control	Plaintext keys in Git repos
Distribution	Interception	Key agreement, encryption	MITM on unauth. key exchange
Usage	Misuse, side channels	API restrictions, auditing	Using encryption key for signing
Rotation	Extended exposure	Automatic rotation policies	Years-old, never-rotated keys
Destruction	Recovery of deleted keys	Secure erasure, crypto shredding	Keys recoverable from old disks

Phase 4: Usage

Keys in use are vulnerable to extraction and misuse. Controls include:

Purpose binding (encryption key can't be used for signing)
Access auditing (log all key operations)
Side-channel protection (constant-time operations)
Secure key loading (from secure storage to protected memory)

Phase 5: Rotation

Keys should be replaced before compromise or cryptographic weakness:

Time-based (rotate annually, monthly, etc.)
Usage-based (rotate after N operations)
Event-based (rotate if potential exposure)
Cryptoperiod (maximum secure lifetime of key type)

Phase 6: Destruction

When keys expire or are replaced, they must be destroyed irrecoverably:

Overwrite key material in memory
Secure erase from storage
For HSMs: zeroize command
Crypto shredding: destroy the key to make encrypted data unrecoverable

The Weakest Link

Security is determined by the weakest point in the lifecycle. A key generated securely, stored in an HSM, but distributed over unencrypted email is as insecure as plaintext. Every phase must meet the security requirements for the key's purpose.

Key Generation and Entropy

A cryptographic key's strength depends entirely on its randomness. A 256-bit key generated from a predictable source (like the current time) might have only 32 bits of effective entropy, reducing the attack space by a factor of 2^224.

Entropy Sources:

Operating systems collect entropy from hardware and environmental sources:

Hardware RNG: CPU instructions (RDRAND/RDSEED on Intel, similar on AMD/ARM)
Device timing: Keyboard, mouse, disk I/O timing variations
Interrupt timing: Network packet arrival times, interrupt jitter
Temperature/voltage: Sensor noise from hardware
Platform-specific: TPM RNG, dedicated security chips

Cryptographically Secure PRNGs (CSPRNGs):

Raw entropy is processed through CSPRNGs to produce uniform, unpredictable output:

Entropy is collected and mixed into an entropy pool
CSPRNG uses hash/block cipher to generate pseudorandom stream
Pool is continuously replenished from sources

Examples:

Linux: /dev/urandom (BLAKE2 or ChaCha20-based)
Windows: BCryptGenRandom (AES-CTR DRBG)
BSD: arc4random (ChaCha20-based)

key_generation.pseudo
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
// Proper Key Generation
 
// === Using System CSPRNG ===
 
// Linux/Unix - read from kernel RNG
function generate_key_linux(bytes):
    file = open("/dev/urandom", "rb")
    key = file.read(bytes)
    file.close()
    return key
 
// Modern Linux - use getrandom() syscall
function generate_key_getrandom(bytes):
    key = getrandom(bytes, GRND_RANDOM)  // Blocks until enough entropy
    return key
 
// Windows - CryptoAPI or CNG
function generate_key_windows(bytes):
    BCryptGenRandom(NULL, buffer, bytes, BCRYPT_USE_SYSTEM_PREFERRED_RNG)
    return buffer
 
// Cross-platform - libsodium
function generate_key_libsodium(bytes):
    key = sodium_malloc(bytes)  // Secure allocation
    randombytes_buf(key, bytes) // Fill from CSPRNG
    return key
 
// === WRONG WAY (NEVER DO THIS) ===
 
// DO NOT use:
// - time() or gettimeofday() as seed
// - rand() or srand() (not cryptographic)
// - Math.random() in browser JavaScript (not cryptographic)
// - /dev/random on modern Linux (urandom is sufficient, random can block)
// - Any predictable or low-entropy source
 
// Bad example:
function BAD_generate_key(bytes):
    srand(time(NULL))  // Only 32 bits of entropy at most!
    key = []
    for i in range(bytes):
        key.append(rand() % 256)
    return key  // COMPLETELY BROKEN

The Debian Disaster

In 2006, a Debian developer "fixed" a compiler warning in OpenSSL by removing code that added entropy. For two years (2006-2008), every key generated by Debian systems came from only 32,767 possible values. All affected SSH keys, SSL certificates, and other keys had to be revoked and regenerated. This affected potentially millions of systems and demonstrated how critical proper entropy is.

Key Generation Best Practices

•Always use system CSPRNG — /dev/urandom on Linux, BCryptGenRandom on Windows, SecRandomCopyBytes on macOS
•Let crypto libraries generate keys — OpenSSL, libsodium, etc. have key generation functions that handle algorithm requirements
•For high-security: use HSM RNG — Hardware Security Modules have certified random number generators
•Verify key properties — Check key passes algorithm requirements (e.g., RSA prime testing)
•Test your entropy source — Run statistical tests on your PRNG output in production configuration

Key Derivation Functions (KDFs)

Key Derivation Functions transform input keying material (possibly non-uniform) into cryptographically strong keys suitable for specific purposes. They serve several essential functions:

1. Extracting keys from non-uniform inputs:

Diffie-Hellman produces a shared secret that's not uniformly distributed. Password-based keys have low entropy. KDFs process these inputs into proper keys.

2. Deriving multiple keys from one master:

From a single master key, derive separate encryption, authentication, and IV generation keys. This prevents key reuse and limits compromise scope.

3. Password-based key derivation:

Transform human-memorable passwords into encryption keys for disk encryption, etc. Requires intentional slowness to resist brute force.

Major KDFs:

HKDF (HMAC-based KDF)

The standard extract-and-expand KDF for protocol key derivation:

// Extract: create uniform pseudorandom key
PRK = HMAC-Hash(salt, input_keying_material)

// Expand: generate output key material
OKM = HMAC-Hash(PRK, info || 0x01) ||
      HMAC-Hash(PRK, T1 || info || 0x02) || ...

Used in TLS 1.3, Signal Protocol, and countless other protocols.

Key Derivation Functions
KDF	Purpose	Speed	Use Case
HKDF	Protocol key derivation	Fast	TLS, Signal: deriving session keys
PBKDF2	Password-based key derivation	Configurable (slow)	LUKS disk encryption, WPA2
scrypt	Password-based, memory-hard	Slow, memory-intensive	Cryptocurrency wallets
Argon2	Password-based, modern	Configurable (slow)	Password hashing, disk encryption
bcrypt	Password hashing	Slow	User password storage

key_derivation_examples.pseudo
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
// Key Derivation Function Usage
 
// === HKDF: Deriving Protocol Keys ===
function derive_session_keys(shared_secret, salt, context):
    // Extract phase
    prk = HKDF_Extract(salt, shared_secret)
    
    // Expand phase - derive multiple keys with distinct info strings
    encryption_key = HKDF_Expand(prk, "encryption", 32)  // 256 bits
    mac_key = HKDF_Expand(prk, "authentication", 32)
    iv = HKDF_Expand(prk, "iv", 12)  // 96 bits for AES-GCM
    
    return (encryption_key, mac_key, iv)
 
// === Argon2: Password-Based Key Derivation ===
function derive_disk_encryption_key(password, salt):
    // Argon2id parameters for disk encryption
    // Tune for ~1 second on target hardware
    memory_cost = 1 << 20  // 1 GB RAM
    time_cost = 4          // 4 iterations
    parallelism = 4        // 4 threads
    key_length = 32        // 256-bit key
    
    key = argon2id(
        password,
        salt,
        memory_cost,
        time_cost,
        parallelism,
        key_length
    )
    
    return key
 
// TLS 1.3 Key Schedule (uses HKDF extensively)
function tls13_derive_keys(shared_secret):
    early_secret = HKDF_Extract(salt=0, IKM=0)
    handshake_secret = HKDF_Extract(
        salt=derive_secret(early_secret, "derived", ""),
        IKM=shared_secret
    )
    master_secret = HKDF_Extract(
        salt=derive_secret(handshake_secret, "derived", ""),
        IKM=0
    )
    
    // Derive client/server write keys, IVs from master_secret
    // ...

When to Use Which KDF

Use HKDF when deriving keys from high-entropy sources (DH shared secrets, random master keys). Use Argon2id when deriving keys from low-entropy sources (passwords, passphrases). Use bcrypt for password verification only (not key derivation). Never use a plain hash (SHA-256(password)) for password-based keys—it's too fast.

Key Storage

Where and how keys are stored fundamentally determines their security. Storage options range from software solutions to dedicated hardware, each with different security properties and cost trade-offs.

Software Key Stores:

Keys encrypted and stored in files or databases:

PKCS#12 files (.p12, .pfx): Encrypted container for certificates and private keys
PEM files: Base64-encoded keys, optionally encrypted
Keystores: Java KeyStore (JKS), Windows Certificate Store, macOS Keychain

Software storage is vulnerable to:

Memory extraction (cold boot, memory dump)
File system access (if protection fails)
Backup exposure (encrypted backups with accessible keys)

Secure Enclaves:

CPU-protected memory regions inaccessible to the OS:

Intel SGX: Encrypted memory enclaves
ARM TrustZone: Secure world partition
Apple Secure Enclave: Dedicated security processor

Provide protection even if OS is compromised, but vulnerable to side-channel attacks (Spectre, etc.).

Key Storage Options
Storage Type	Security Level	Cost	Key Extraction	Use Case
Plaintext files	Very Low	Free	Trivial	Never for production
Encrypted files	Low-Medium	Free	Password attack	Development, low-value secrets
OS keystore	Medium	Free	Admin access	User credentials, certificates
Secure Enclave	Medium-High	Hardware	Side-channel attacks	Device keys, biometrics
TPM	High	$5-50	Difficult (bound to device)	Disk encryption keys, secure boot
HSM	Very High	$1000+	Nearly impossible	CA keys, financial systems

Trusted Platform Module (TPM):

A dedicated security chip providing:

Secure key generation and storage
Key sealing to platform configuration (PCR values)
Attestation (proving system state)
Cryptographic operations without exposing keys

TPMs are ubiquitous in modern PCs and are used for:

BitLocker disk encryption key storage
Measured boot attestation
VPN and Wi-Fi credential protection

Hardware Security Modules (HSMs):

Dedicated cryptographic processors with:

FIPS 140-2/3 certification (Level 3+ provides tamper response)
Keys never leave the device in plaintext
Physical tamper detection and response
Multi-party key custody (m-of-n schemes)
Audit logging of all operations

Used for CA root keys, banking systems, code signing, and any key whose compromise would be catastrophic.

Cloud Key Management Services

Cloud providers offer managed HSMs and key management: AWS KMS, Google Cloud KMS, Azure Key Vault. These provide many HSM benefits (key never exposed) with easier operations. Keys can be customer-managed (uploaded) or cloud-generated. Consider data residency requirements and trust model when choosing.

Key Storage in Operating Systems

Each major operating system provides built-in key storage facilities with varying security properties.

Operating System Key Storage

•Windows Certificate Store — Managed via certmgr, accessed through CryptoAPI/CNG. Stores user and machine certificates/keys. DPAPI encrypts user keys with login password. Can use TPM for protected keys.
•macOS Keychain — Keychain Access app or security CLI. Encrypts with login password or dedicated keychain password. Secure Enclave protects biometric-gated keys. iCloud Keychain syncs across devices (end-to-end encrypted).
•Linux Kernel Keyring — In-kernel key storage (keyrings, keyctl). Supports various key types (user, logon, encrypted). Keys protected by process context and capabilities. Used by ecryptfs, NFS, CIFS for encryption keys.
•Linux Secret Service — D-Bus API (libsecret) for userspace secrets. Backends: GNOME Keyring, KDE Wallet. Encrypted with login password or hardware token. Used by browsers, email clients, SSH agents.
•TPM Integration — All major OSes can seal keys to TPM. Windows: BitLocker, Windows Hello. Linux: tpm2-tools, clevis for LUKS. macOS: T2/Apple Silicon Secure Enclave.

os_key_storage.sh
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
# Operating System Key Storage Examples
 
# === Linux Kernel Keyring ===
# Add a key to session keyring
keyctl add user mykey "secret_data" @s
# View session keyring
keyctl show @s
# Read a key
keyctl print <key_id>
# Set key timeout (auto-expire)
keyctl timeout <key_id> 3600
 
# === Linux Secret Service (via secret-tool) ===
# Store a secret
secret-tool store --label='API Key' service myapp username admin
# Retrieve a secret
secret-tool lookup service myapp username admin
 
# === macOS Keychain ===
# Add password to keychain
security add-generic-password -s "service_name" -a "account" -w "password"
# Find and show password
security find-generic-password -s "service_name" -a "account" -w
# List keychains
security list-keychains
 
# === Windows Certificate Store ===
# Import certificate (PowerShell)
Import-Certificate -FilePath "cert.cer" -CertStoreLocation Cert:\CurrentUser\My
# List certificates
Get-ChildItem -Path Cert:\CurrentUser\My
# Export certificate (with private key requires proper rights)
Export-PfxCertificate -Cert $cert -FilePath "export.pfx" -Password $pwd
 
# === TPM Key Sealing (Linux tpm2-tools) ===
# Create key sealed to current PCR values
tpm2_create -C primary.ctx -u sealed.pub -r sealed.priv -i secret.txt
# Unseal (only works with same PCR values)
tpm2_unseal -c key.ctx -o unsealed.txt

Key Storage Anti-Patterns

NEVER store keys in plaintext config files, source code, or environment variables (exposed in process lists). NEVER commit keys to Git repositories (they persist in history). NEVER hardcode keys in binaries (easily extracted with strings). ALWAYS use the appropriate keystore for your platform, or a proper secrets management system (HashiCorp Vault, etc.).

Key Distribution

Getting keys to authorized parties securely is one of the oldest problems in cryptography. Modern solutions combine multiple approaches.

Key Agreement Protocols:

Parties derive a shared secret without transmitting it:

Diffie-Hellman (DH, ECDH): Classic approach, requires authentication to prevent MITM
Authenticated Key Exchange (AKE): Combines DH with signatures or pre-shared keys
Password-Authenticated Key Exchange (PAKE): SRP, OPAQUE derive strong keys from weak passwords

Key Encapsulation:

Encrypt keys with recipient's public key:

Generate random symmetric key
Encrypt data with symmetric key
Encrypt symmetric key with recipient's RSA/ECC public key
Transmit both encrypted key and encrypted data

Key Wrapping:

Encrypt keys with other keys for storage/transit:

AES-KW (Key Wrap): Standard for encrypting keys with keys
Key hierarchy: Master key wraps data keys, data keys encrypt data
Key rotation: Old key decrypts data, re-encrypts with new key

Key Distribution Methods
Method	Mechanism	Security Property	Use Case
Pre-shared key	Out-of-band delivery	Symmetric, requires secure channel	VPN, WPA2-PSK
Public key encryption	Encrypt to recipient's pubkey	Requires authentic public key	Email (PGP/S/MIME)
Key agreement (DH)	Compute shared secret	Forward secrecy (ephemeral)	TLS, Signal
Key server	Retrieve keys from trusted server	Server must be trusted	Kerberos, enterprise PKI
Web of Trust	Keys signed by peers	Decentralized trust	PGP network
Certificate Authority	Trusted third party signs	Centralized trust	TLS/SSL

key_distribution.pseudo
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
// Key Distribution Patterns
 
// === Pattern 1: Key Hierarchy ===
// Used in disk encryption, database encryption, cloud KMS
 
function setup_key_hierarchy():
    // Level 0: Key Encryption Key (KEK) - stored in HSM or protected storage
    kek = generate_key(256)
    store_in_hsm(kek, key_id="master")
    
    // Level 1: Data Encryption Keys (DEK) - wrapped by KEK
    dek1 = generate_key(256)
    wrapped_dek1 = aes_key_wrap(kek, dek1)
    store_in_database(wrapped_dek1, table="keys", prefix="table_customers")
    
    // To encrypt data:
    dek = aes_key_unwrap(kek, wrapped_dek1)
    ciphertext = encrypt(dek, data)
 
// === Pattern 2: TLS Key Exchange (Simplified) ===
function tls13_key_exchange(client, server):
    // Client generates ephemeral ECDHE key pair
    client_private = generate_ecdhe_key()
    client_public = derive_public(client_private)
    
    // Server generates ephemeral ECDHE key pair
    server_private = generate_ecdhe_key()
    server_public = derive_public(server_private)
    
    // Exchange public values (signed by server's long-term key)
    // ...
    
    // Both compute same shared secret
    shared_secret = ecdh(client_private, server_public)
                  = ecdh(server_private, client_public)
    
    // Derive session keys using HKDF
    (client_key, server_key, client_iv, server_iv) = 
        hkdf_derive_keys(shared_secret, transcript_hash)
    
    return handshake_complete
 
// === Pattern 3: Envelope Encryption (Cloud) ===
function envelope_encrypt(data, kms_key_id):
    // Request fresh DEK from KMS
    (plaintext_dek, encrypted_dek) = kms_generate_data_key(kms_key_id)
    
    // Encrypt data with DEK
    ciphertext = aes_gcm_encrypt(plaintext_dek, data)
    
    // Immediately erase plaintext DEK
    secure_zero(plaintext_dek)
    
    // Store encrypted DEK alongside ciphertext
    return (encrypted_dek, ciphertext)

Envelope Encryption Pattern

Envelope encryption is the standard pattern for data-at-rest encryption. Generate a random Data Encryption Key (DEK) for each object. Encrypt the data with the DEK. Encrypt the DEK with a Key Encryption Key (KEK) stored securely (HSM/KMS). Store encrypted DEK with encrypted data. This allows key rotation (re-wrap DEKs with new KEK) without re-encrypting all data.

Key Rotation and Destruction

Keys should not be used indefinitely. Key rotation replaces keys periodically; key destruction ensures old keys cannot be recovered.

Why Rotate Keys?

Limit blast radius: If a key is compromised, only data encrypted since last rotation is affected
Reduce exposure: Less data is encrypted with each key, limiting cryptanalytic opportunities
Compliance: Many standards (PCI-DSS, HIPAA) require periodic rotation
Algorithm aging: Migrate to stronger algorithms over time
Personnel changes: Rotate keys when key custodians leave

Rotation Strategies:

Automatic rotation: System rotates keys on schedule (Azure Key Vault, AWS KMS)
Triggered rotation: Rotate on suspected compromise or personnel change
Gradual rotation: New key for new data, old key for decryption during transition
Immediate rotation: Replace key, re-encrypt all data (expensive but cleanest)

NIST Cryptoperiod Recommendations (SP 800-57)
Key Type	Originator Usage	Recipient Usage	Notes
Symmetric encryption	1-2 years	Decryption lifetime	Data key for encryption
Symmetric auth (MAC)	1-2 years	Same as originator	Message authentication
Asymmetric signature	1-3 years	Verification longer	Signing private key
Asymmetric key transport	1-2 years	Decryption lifetime	RSA encryption key
Root CA key	10-20 years	Certificate lifetime	Highest protection required

key_rotation.pseudo
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
// Key Rotation Patterns
 
// === Pattern 1: Key Versioning ===
// Store multiple key versions, encrypt with latest, decrypt with any
class VersionedKeystore:
    def get_current_key():
        return keys[current_version]
    
    def get_key(version):
        return keys[version]
    
    def rotate():
        new_key = generate_key()
        current_version += 1
        keys[current_version] = new_key
        schedule_old_key_deletion(current_version - 2)
 
// Encryption includes version
function encrypt_with_version(data):
    key, version = keystore.get_current_key()
    ciphertext = encrypt(key, data)
    return (version, ciphertext)
 
// Decryption uses stored version
function decrypt_with_version(version, ciphertext):
    key = keystore.get_key(version)
    return decrypt(key, ciphertext)
 
// === Secure Key Destruction ===
function destroy_key_secure(key):
    // 1. Overwrite memory with zeros
    for i in range(len(key)):
        key[i] = 0
    
    // 2. Overwrite with random (defense in depth)
    random_bytes = generate_random(len(key))
    for i in range(len(key)):
        key[i] = random_bytes[i]
    
    // 3. Zeroise again
    for i in range(len(key)):
        key[i] = 0
    
    // 4. Memory barrier to prevent optimizer removing
    memory_barrier()
    
    // 5. Free memory (may be reallocated)
    // Note: SSD/swap may retain copies - use mlock() and secure memory
 
// === Crypto Shredding ===
// Delete the key to make all encrypted data unrecoverable
function crypto_shred(key_id):
    // Remove key from all storage locations
    keystore.delete(key_id)
    hsm.destroy_key(key_id)
    backup.purge_key(key_id)
    
    // All data encrypted with this key is now unrecoverable
    // Much faster than securely erasing terabytes of data

Crypto Shredding for Data Destruction

Crypto shredding is an elegant approach to data destruction: instead of securely erasing terabytes of data, destroy the encryption key. The encrypted data becomes cryptographically unrecoverable. This is faster, more reliable, and works even when you can't access the storage (cloud, distributed systems). Requires proper key management—the key must be the only way to decrypt.

Summary: Key Management

We've explored the complete lifecycle of cryptographic key management—from generation to destruction—and the operational practices that determine whether cryptographic security is achieved in practice.

Key Takeaways

•Key management spans generation, storage, distribution, usage, rotation, and destruction — Security depends on the weakest phase.
•Key generation requires proper entropy — Use system CSPRNGs (/dev/urandom, BCryptGenRandom). Never use predictable sources.
•KDFs transform inputs into proper keys — HKDF for high-entropy sources, Argon2id for passwords.
•Key storage ranges from software to HSMs — Match storage security to key value. Never store keys in plaintext.
•Operating systems provide built-in keystores — Windows Certificate Store, macOS Keychain, Linux Keyring—use them.
•Key distribution uses agreement, encapsulation, or wrapping — TLS uses ephemeral key agreement for forward secrecy.
•Keys must be rotated and eventually destroyed — Crypto shredding provides fast, reliable data destruction.

Module Complete: Cryptography Basics

With this page, you've completed the Cryptography Basics module. You now understand:

Symmetric encryption: AES, modes of operation, disk encryption
Asymmetric encryption: RSA, ECC, key exchange, hybrid encryption
Hash functions: SHA-256, MACs, password hashing
Digital signatures: RSA-PSS, Ed25519, certificates
Key management: The complete lifecycle from generation to destruction

These cryptographic primitives are the building blocks of operating system security—protecting data at rest (disk encryption), data in transit (TLS), code authenticity (signatures), and user credentials (password hashing). Understanding them deeply enables you to design, implement, and audit secure systems.

Module Complete

You now understand cryptographic key management—the operational practices that determine whether mathematically secure cryptography provides security in the real world. This knowledge is essential for implementing disk encryption, secure boot, credential management, and any system that relies on cryptographic secrets.

5 / 5

Loading learning content...

Operating SystemsSecurity Fundamentals

Cryptography Basics

LevelIntermediate

Duration90 mins

TopicSecurity Fundamentals

5 / 5

Key Management

Where Cryptography Meets Reality

Key management is where cryptographic theory meets operational reality. It encompasses every aspect of handling cryptographic keys throughout their lifecycle:

Generation: Creating keys with sufficient randomness
Storage: Protecting keys at rest from unauthorized access
Distribution: Delivering keys securely to authorized parties
Usage: Controlling and auditing how keys are used
Rotation: Replacing keys before they're compromised or expire
Destruction: Securely erasing keys when no longer needed

What You Will Learn

The Key Lifecycle

Every cryptographic key passes through distinct phases, each with specific security requirements and potential vulnerabilities.

Phase 1: Generation

Keys must be generated with sufficient entropy (randomness). A 256-bit key that can be predicted or has patterns provides far less than 256 bits of security. Proper key generation requires:

Cryptographically secure random number generator (CSPRNG)
Sufficient entropy source (hardware RNG, environmental noise)
Verification that key meets algorithm requirements

Phase 2: Storage

Unauthorized reads (access control, encryption)
Memory inspection (secure memory allocation)
Persistence in deleted files (secure erasure)

Phase 3: Distribution

Keys must reach authorized parties without interception. Methods include:

Key agreement protocols (Diffie-Hellman)
Key encapsulation (encrypted key transport)
Out-of-band delivery (separate secure channel)
Key derivation (derive from shared master secret)

Key Lifecycle Phases and Security Considerations
Phase	Primary Threat	Protection Mechanism	Failure Example
Generation	Weak randomness	Hardware RNG, proper CSPRNG	Debian OpenSSL (predictable keys)
Storage	Unauthorized access	Encryption, HSMs, access control	Plaintext keys in Git repos
Distribution	Interception	Key agreement, encryption	MITM on unauth. key exchange
Usage	Misuse, side channels	API restrictions, auditing	Using encryption key for signing
Rotation	Extended exposure	Automatic rotation policies	Years-old, never-rotated keys
Destruction	Recovery of deleted keys	Secure erasure, crypto shredding	Keys recoverable from old disks

Phase 4: Usage

Keys in use are vulnerable to extraction and misuse. Controls include:

Purpose binding (encryption key can't be used for signing)
Access auditing (log all key operations)
Side-channel protection (constant-time operations)
Secure key loading (from secure storage to protected memory)

Phase 5: Rotation

Keys should be replaced before compromise or cryptographic weakness:

Time-based (rotate annually, monthly, etc.)
Usage-based (rotate after N operations)
Event-based (rotate if potential exposure)
Cryptoperiod (maximum secure lifetime of key type)

Phase 6: Destruction

When keys expire or are replaced, they must be destroyed irrecoverably:

Overwrite key material in memory
Secure erase from storage
For HSMs: zeroize command
Crypto shredding: destroy the key to make encrypted data unrecoverable

The Weakest Link

Key Generation and Entropy

Entropy Sources:

Operating systems collect entropy from hardware and environmental sources:

Hardware RNG: CPU instructions (RDRAND/RDSEED on Intel, similar on AMD/ARM)
Device timing: Keyboard, mouse, disk I/O timing variations
Interrupt timing: Network packet arrival times, interrupt jitter
Temperature/voltage: Sensor noise from hardware
Platform-specific: TPM RNG, dedicated security chips

Cryptographically Secure PRNGs (CSPRNGs):

Raw entropy is processed through CSPRNGs to produce uniform, unpredictable output:

Entropy is collected and mixed into an entropy pool
CSPRNG uses hash/block cipher to generate pseudorandom stream
Pool is continuously replenished from sources

Examples:

Linux: /dev/urandom (BLAKE2 or ChaCha20-based)
Windows: BCryptGenRandom (AES-CTR DRBG)
BSD: arc4random (ChaCha20-based)

key_generation.pseudo
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
// Proper Key Generation
 
// === Using System CSPRNG ===
 
// Linux/Unix - read from kernel RNG
function generate_key_linux(bytes):
    file = open("/dev/urandom", "rb")
    key = file.read(bytes)
    file.close()
    return key
 
// Modern Linux - use getrandom() syscall
function generate_key_getrandom(bytes):
    key = getrandom(bytes, GRND_RANDOM)  // Blocks until enough entropy
    return key
 
// Windows - CryptoAPI or CNG
function generate_key_windows(bytes):
    BCryptGenRandom(NULL, buffer, bytes, BCRYPT_USE_SYSTEM_PREFERRED_RNG)
    return buffer
 
// Cross-platform - libsodium
function generate_key_libsodium(bytes):
    key = sodium_malloc(bytes)  // Secure allocation
    randombytes_buf(key, bytes) // Fill from CSPRNG
    return key
 
// === WRONG WAY (NEVER DO THIS) ===
 
// DO NOT use:
// - time() or gettimeofday() as seed
// - rand() or srand() (not cryptographic)
// - Math.random() in browser JavaScript (not cryptographic)
// - /dev/random on modern Linux (urandom is sufficient, random can block)
// - Any predictable or low-entropy source
 
// Bad example:
function BAD_generate_key(bytes):
    srand(time(NULL))  // Only 32 bits of entropy at most!
    key = []
    for i in range(bytes):
        key.append(rand() % 256)
    return key  // COMPLETELY BROKEN

The Debian Disaster

Key Generation Best Practices

•Always use system CSPRNG — /dev/urandom on Linux, BCryptGenRandom on Windows, SecRandomCopyBytes on macOS
•Let crypto libraries generate keys — OpenSSL, libsodium, etc. have key generation functions that handle algorithm requirements
•For high-security: use HSM RNG — Hardware Security Modules have certified random number generators
•Verify key properties — Check key passes algorithm requirements (e.g., RSA prime testing)
•Test your entropy source — Run statistical tests on your PRNG output in production configuration

Key Derivation Functions (KDFs)

Key Derivation Functions transform input keying material (possibly non-uniform) into cryptographically strong keys suitable for specific purposes. They serve several essential functions:

1. Extracting keys from non-uniform inputs:

Diffie-Hellman produces a shared secret that's not uniformly distributed. Password-based keys have low entropy. KDFs process these inputs into proper keys.

2. Deriving multiple keys from one master:

From a single master key, derive separate encryption, authentication, and IV generation keys. This prevents key reuse and limits compromise scope.

3. Password-based key derivation:

Transform human-memorable passwords into encryption keys for disk encryption, etc. Requires intentional slowness to resist brute force.

Major KDFs:

HKDF (HMAC-based KDF)

The standard extract-and-expand KDF for protocol key derivation:

// Extract: create uniform pseudorandom key
PRK = HMAC-Hash(salt, input_keying_material)

// Expand: generate output key material
OKM = HMAC-Hash(PRK, info || 0x01) ||
      HMAC-Hash(PRK, T1 || info || 0x02) || ...

Used in TLS 1.3, Signal Protocol, and countless other protocols.

Key Derivation Functions
KDF	Purpose	Speed	Use Case
HKDF	Protocol key derivation	Fast	TLS, Signal: deriving session keys
PBKDF2	Password-based key derivation	Configurable (slow)	LUKS disk encryption, WPA2
scrypt	Password-based, memory-hard	Slow, memory-intensive	Cryptocurrency wallets
Argon2	Password-based, modern	Configurable (slow)	Password hashing, disk encryption
bcrypt	Password hashing	Slow	User password storage

key_derivation_examples.pseudo
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
// Key Derivation Function Usage
 
// === HKDF: Deriving Protocol Keys ===
function derive_session_keys(shared_secret, salt, context):
    // Extract phase
    prk = HKDF_Extract(salt, shared_secret)
    
    // Expand phase - derive multiple keys with distinct info strings
    encryption_key = HKDF_Expand(prk, "encryption", 32)  // 256 bits
    mac_key = HKDF_Expand(prk, "authentication", 32)
    iv = HKDF_Expand(prk, "iv", 12)  // 96 bits for AES-GCM
    
    return (encryption_key, mac_key, iv)
 
// === Argon2: Password-Based Key Derivation ===
function derive_disk_encryption_key(password, salt):
    // Argon2id parameters for disk encryption
    // Tune for ~1 second on target hardware
    memory_cost = 1 << 20  // 1 GB RAM
    time_cost = 4          // 4 iterations
    parallelism = 4        // 4 threads
    key_length = 32        // 256-bit key
    
    key = argon2id(
        password,
        salt,
        memory_cost,
        time_cost,
        parallelism,
        key_length
    )
    
    return key
 
// TLS 1.3 Key Schedule (uses HKDF extensively)
function tls13_derive_keys(shared_secret):
    early_secret = HKDF_Extract(salt=0, IKM=0)
    handshake_secret = HKDF_Extract(
        salt=derive_secret(early_secret, "derived", ""),
        IKM=shared_secret
    )
    master_secret = HKDF_Extract(
        salt=derive_secret(handshake_secret, "derived", ""),
        IKM=0
    )
    
    // Derive client/server write keys, IVs from master_secret
    // ...

When to Use Which KDF

Key Storage

Software Key Stores:

Keys encrypted and stored in files or databases:

PKCS#12 files (.p12, .pfx): Encrypted container for certificates and private keys
PEM files: Base64-encoded keys, optionally encrypted
Keystores: Java KeyStore (JKS), Windows Certificate Store, macOS Keychain

Software storage is vulnerable to:

Memory extraction (cold boot, memory dump)
File system access (if protection fails)
Backup exposure (encrypted backups with accessible keys)

Secure Enclaves:

CPU-protected memory regions inaccessible to the OS:

Intel SGX: Encrypted memory enclaves
ARM TrustZone: Secure world partition
Apple Secure Enclave: Dedicated security processor

Provide protection even if OS is compromised, but vulnerable to side-channel attacks (Spectre, etc.).

Key Storage Options
Storage Type	Security Level	Cost	Key Extraction	Use Case
Plaintext files	Very Low	Free	Trivial	Never for production
Encrypted files	Low-Medium	Free	Password attack	Development, low-value secrets
OS keystore	Medium	Free	Admin access	User credentials, certificates
Secure Enclave	Medium-High	Hardware	Side-channel attacks	Device keys, biometrics
TPM	High	$5-50	Difficult (bound to device)	Disk encryption keys, secure boot
HSM	Very High	$1000+	Nearly impossible	CA keys, financial systems

Trusted Platform Module (TPM):

A dedicated security chip providing:

Secure key generation and storage
Key sealing to platform configuration (PCR values)
Attestation (proving system state)
Cryptographic operations without exposing keys

TPMs are ubiquitous in modern PCs and are used for:

BitLocker disk encryption key storage
Measured boot attestation
VPN and Wi-Fi credential protection

Hardware Security Modules (HSMs):

Dedicated cryptographic processors with:

FIPS 140-2/3 certification (Level 3+ provides tamper response)
Keys never leave the device in plaintext
Physical tamper detection and response
Multi-party key custody (m-of-n schemes)
Audit logging of all operations

Used for CA root keys, banking systems, code signing, and any key whose compromise would be catastrophic.

Cloud Key Management Services

Key Storage in Operating Systems

Each major operating system provides built-in key storage facilities with varying security properties.

Operating System Key Storage

•Windows Certificate Store — Managed via certmgr, accessed through CryptoAPI/CNG. Stores user and machine certificates/keys. DPAPI encrypts user keys with login password. Can use TPM for protected keys.
•macOS Keychain — Keychain Access app or security CLI. Encrypts with login password or dedicated keychain password. Secure Enclave protects biometric-gated keys. iCloud Keychain syncs across devices (end-to-end encrypted).
•Linux Kernel Keyring — In-kernel key storage (keyrings, keyctl). Supports various key types (user, logon, encrypted). Keys protected by process context and capabilities. Used by ecryptfs, NFS, CIFS for encryption keys.
•Linux Secret Service — D-Bus API (libsecret) for userspace secrets. Backends: GNOME Keyring, KDE Wallet. Encrypted with login password or hardware token. Used by browsers, email clients, SSH agents.
•TPM Integration — All major OSes can seal keys to TPM. Windows: BitLocker, Windows Hello. Linux: tpm2-tools, clevis for LUKS. macOS: T2/Apple Silicon Secure Enclave.

os_key_storage.sh
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
# Operating System Key Storage Examples
 
# === Linux Kernel Keyring ===
# Add a key to session keyring
keyctl add user mykey "secret_data" @s
# View session keyring
keyctl show @s
# Read a key
keyctl print <key_id>
# Set key timeout (auto-expire)
keyctl timeout <key_id> 3600
 
# === Linux Secret Service (via secret-tool) ===
# Store a secret
secret-tool store --label='API Key' service myapp username admin
# Retrieve a secret
secret-tool lookup service myapp username admin
 
# === macOS Keychain ===
# Add password to keychain
security add-generic-password -s "service_name" -a "account" -w "password"
# Find and show password
security find-generic-password -s "service_name" -a "account" -w
# List keychains
security list-keychains
 
# === Windows Certificate Store ===
# Import certificate (PowerShell)
Import-Certificate -FilePath "cert.cer" -CertStoreLocation Cert:\CurrentUser\My
# List certificates
Get-ChildItem -Path Cert:\CurrentUser\My
# Export certificate (with private key requires proper rights)
Export-PfxCertificate -Cert $cert -FilePath "export.pfx" -Password $pwd
 
# === TPM Key Sealing (Linux tpm2-tools) ===
# Create key sealed to current PCR values
tpm2_create -C primary.ctx -u sealed.pub -r sealed.priv -i secret.txt
# Unseal (only works with same PCR values)
tpm2_unseal -c key.ctx -o unsealed.txt

Key Storage Anti-Patterns

Key Distribution

Getting keys to authorized parties securely is one of the oldest problems in cryptography. Modern solutions combine multiple approaches.

Key Agreement Protocols:

Parties derive a shared secret without transmitting it:

Diffie-Hellman (DH, ECDH): Classic approach, requires authentication to prevent MITM
Authenticated Key Exchange (AKE): Combines DH with signatures or pre-shared keys
Password-Authenticated Key Exchange (PAKE): SRP, OPAQUE derive strong keys from weak passwords

Key Encapsulation:

Encrypt keys with recipient's public key:

Generate random symmetric key
Encrypt data with symmetric key
Encrypt symmetric key with recipient's RSA/ECC public key
Transmit both encrypted key and encrypted data

Key Wrapping:

Encrypt keys with other keys for storage/transit:

AES-KW (Key Wrap): Standard for encrypting keys with keys
Key hierarchy: Master key wraps data keys, data keys encrypt data
Key rotation: Old key decrypts data, re-encrypts with new key

Key Distribution Methods
Method	Mechanism	Security Property	Use Case
Pre-shared key	Out-of-band delivery	Symmetric, requires secure channel	VPN, WPA2-PSK
Public key encryption	Encrypt to recipient's pubkey	Requires authentic public key	Email (PGP/S/MIME)
Key agreement (DH)	Compute shared secret	Forward secrecy (ephemeral)	TLS, Signal
Key server	Retrieve keys from trusted server	Server must be trusted	Kerberos, enterprise PKI
Web of Trust	Keys signed by peers	Decentralized trust	PGP network
Certificate Authority	Trusted third party signs	Centralized trust	TLS/SSL

key_distribution.pseudo
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
// Key Distribution Patterns
 
// === Pattern 1: Key Hierarchy ===
// Used in disk encryption, database encryption, cloud KMS
 
function setup_key_hierarchy():
    // Level 0: Key Encryption Key (KEK) - stored in HSM or protected storage
    kek = generate_key(256)
    store_in_hsm(kek, key_id="master")
    
    // Level 1: Data Encryption Keys (DEK) - wrapped by KEK
    dek1 = generate_key(256)
    wrapped_dek1 = aes_key_wrap(kek, dek1)
    store_in_database(wrapped_dek1, table="keys", prefix="table_customers")
    
    // To encrypt data:
    dek = aes_key_unwrap(kek, wrapped_dek1)
    ciphertext = encrypt(dek, data)
 
// === Pattern 2: TLS Key Exchange (Simplified) ===
function tls13_key_exchange(client, server):
    // Client generates ephemeral ECDHE key pair
    client_private = generate_ecdhe_key()
    client_public = derive_public(client_private)
    
    // Server generates ephemeral ECDHE key pair
    server_private = generate_ecdhe_key()
    server_public = derive_public(server_private)
    
    // Exchange public values (signed by server's long-term key)
    // ...
    
    // Both compute same shared secret
    shared_secret = ecdh(client_private, server_public)
                  = ecdh(server_private, client_public)
    
    // Derive session keys using HKDF
    (client_key, server_key, client_iv, server_iv) = 
        hkdf_derive_keys(shared_secret, transcript_hash)
    
    return handshake_complete
 
// === Pattern 3: Envelope Encryption (Cloud) ===
function envelope_encrypt(data, kms_key_id):
    // Request fresh DEK from KMS
    (plaintext_dek, encrypted_dek) = kms_generate_data_key(kms_key_id)
    
    // Encrypt data with DEK
    ciphertext = aes_gcm_encrypt(plaintext_dek, data)
    
    // Immediately erase plaintext DEK
    secure_zero(plaintext_dek)
    
    // Store encrypted DEK alongside ciphertext
    return (encrypted_dek, ciphertext)

Envelope Encryption Pattern

Key Rotation and Destruction

Keys should not be used indefinitely. Key rotation replaces keys periodically; key destruction ensures old keys cannot be recovered.

Why Rotate Keys?

Limit blast radius: If a key is compromised, only data encrypted since last rotation is affected
Reduce exposure: Less data is encrypted with each key, limiting cryptanalytic opportunities
Compliance: Many standards (PCI-DSS, HIPAA) require periodic rotation
Algorithm aging: Migrate to stronger algorithms over time
Personnel changes: Rotate keys when key custodians leave

Rotation Strategies:

Automatic rotation: System rotates keys on schedule (Azure Key Vault, AWS KMS)
Triggered rotation: Rotate on suspected compromise or personnel change
Gradual rotation: New key for new data, old key for decryption during transition
Immediate rotation: Replace key, re-encrypt all data (expensive but cleanest)

NIST Cryptoperiod Recommendations (SP 800-57)
Key Type	Originator Usage	Recipient Usage	Notes
Symmetric encryption	1-2 years	Decryption lifetime	Data key for encryption
Symmetric auth (MAC)	1-2 years	Same as originator	Message authentication
Asymmetric signature	1-3 years	Verification longer	Signing private key
Asymmetric key transport	1-2 years	Decryption lifetime	RSA encryption key
Root CA key	10-20 years	Certificate lifetime	Highest protection required

key_rotation.pseudo
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
// Key Rotation Patterns
 
// === Pattern 1: Key Versioning ===
// Store multiple key versions, encrypt with latest, decrypt with any
class VersionedKeystore:
    def get_current_key():
        return keys[current_version]
    
    def get_key(version):
        return keys[version]
    
    def rotate():
        new_key = generate_key()
        current_version += 1
        keys[current_version] = new_key
        schedule_old_key_deletion(current_version - 2)
 
// Encryption includes version
function encrypt_with_version(data):
    key, version = keystore.get_current_key()
    ciphertext = encrypt(key, data)
    return (version, ciphertext)
 
// Decryption uses stored version
function decrypt_with_version(version, ciphertext):
    key = keystore.get_key(version)
    return decrypt(key, ciphertext)
 
// === Secure Key Destruction ===
function destroy_key_secure(key):
    // 1. Overwrite memory with zeros
    for i in range(len(key)):
        key[i] = 0
    
    // 2. Overwrite with random (defense in depth)
    random_bytes = generate_random(len(key))
    for i in range(len(key)):
        key[i] = random_bytes[i]
    
    // 3. Zeroise again
    for i in range(len(key)):
        key[i] = 0
    
    // 4. Memory barrier to prevent optimizer removing
    memory_barrier()
    
    // 5. Free memory (may be reallocated)
    // Note: SSD/swap may retain copies - use mlock() and secure memory
 
// === Crypto Shredding ===
// Delete the key to make all encrypted data unrecoverable
function crypto_shred(key_id):
    // Remove key from all storage locations
    keystore.delete(key_id)
    hsm.destroy_key(key_id)
    backup.purge_key(key_id)
    
    // All data encrypted with this key is now unrecoverable
    // Much faster than securely erasing terabytes of data

Crypto Shredding for Data Destruction

Summary: Key Management

Key Takeaways

•Key management spans generation, storage, distribution, usage, rotation, and destruction — Security depends on the weakest phase.
•Key generation requires proper entropy — Use system CSPRNGs (/dev/urandom, BCryptGenRandom). Never use predictable sources.
•KDFs transform inputs into proper keys — HKDF for high-entropy sources, Argon2id for passwords.
•Key storage ranges from software to HSMs — Match storage security to key value. Never store keys in plaintext.
•Operating systems provide built-in keystores — Windows Certificate Store, macOS Keychain, Linux Keyring—use them.
•Key distribution uses agreement, encapsulation, or wrapping — TLS uses ephemeral key agreement for forward secrecy.
•Keys must be rotated and eventually destroyed — Crypto shredding provides fast, reliable data destruction.

Module Complete: Cryptography Basics

With this page, you've completed the Cryptography Basics module. You now understand:

Symmetric encryption: AES, modes of operation, disk encryption
Asymmetric encryption: RSA, ECC, key exchange, hybrid encryption
Hash functions: SHA-256, MACs, password hashing
Digital signatures: RSA-PSS, Ed25519, certificates
Key management: The complete lifecycle from generation to destruction

Module Complete

5 / 5