Schlüsselmanagement - Kryptografische Schlüssel sicher verwalten

Key management is the Achilles' heel of cryptography. Even the strongest encryption is worthless if keys are generated poorly, stored insecurely, or never rotated. "The security of an encrypted system does not depend on mathematics—it depends on the keys."

Key Lifecycle

Key Management Lifecycle:

Phase 1: Key Generation
  → Cryptographically secure random numbers (CSPRNG)
  → Issues:
    - Weak entropy sources (virtual machines have less entropy)
    - Hardware RNG vs. software RNG
  → Linux: /dev/urandom (since kernel 5.x: sufficient)
  → Python: secrets.token_bytes(32)  # Not: random.random()!
  → Hardware recommendation: HSM generates keys internally (never leaves the device!)
  → Key strength: AES-256, RSA-4096 (legacy), or ECDSA P-384

Phase 2: Key Distribution
  → How does the key reach the authorized recipient?
  → Problem: "Key Distribution Problem" – how do you share keys securely?
  → Asymmetric cryptography: exchange public keys → send encrypted
  → Key wrapping: encrypt the key with another key
  → Key escrow: deposit the key with a trusted party

Phase 3: Key Storage
  → Worst practice: Key in configuration file (plaintext!)
  → Fair: Encrypted in database
  → Good: Key Management Service (AWS KMS, Azure Key Vault, HashiCorp Vault)
  → Optimal: HSM (Hardware Security Module)

Phase 4: Key Rotation
  → Regular renewal limits the extent of damage in the event of a compromise
  → Recommended rotation intervals:
    Data Encryption Key (DEK): monthly (or per file)
    Key Encryption Key (KEK): annually
    TLS certificates: before expiration (at least 90 days before expiration)
    SSH keys: annually
    API keys: annually or when an employee leaves
  → Automatic rotation: KMS and Vault can handle this!

Phase 5: Key Revocation
  → Compromised keys must be invalidated immediately
  → X.509 certificates: CRL (Certificate Revocation List) or OCSP
  → OCSP stapling: Server provides OCSP response via TLS handshake

Phase 6: Key Destruction
  → Securely delete cryptographic keys!
  → SSD: Standard erasure is NOT sufficient (flash cells)
  → Secure erasure: Crypto-Erase (erase keys = make data unreadable)
  → HSM: Secure zeroization (cryptographic erasure)
  → Documentation: when and why erased (compliance!)

Hardware Security Modules (HSMs)

What is an HSM?

Hardware Security Module:
  → Dedicated hardware for cryptographic operations
  → Keys NEVER leave the HSM in unencrypted form!
  → Tamper-proof: physical tampering → automatic key deletion
  → FIPS 140-2/3 Level 3 certified (highest security level)
  → NSS (Non-Stop Security): active even when under attack

Uses of HSMs:
  → CA root certificates: Root CA keys in HSM (non-transferable!)
  → Database encryption: Master keys in HSM
  → Code signing: Signing keys in HSM
  → Payments: PCI DSS requires HSM for card encryption
  → Kubernetes/Cloud: Encryption keys for etcd in HSM

HSM products:

On-premises:
  Thales Luna (SafeNet):  Market leader, FIPS 140-2 Level 3, starting at 20k EUR
  nCipher nShield:        nForce, Connect XC, starting at 15k EUR
  Utimaco SecurityServer: German company, BSI-approved
  Micro HSM (for SMEs):    Nitrokey HSM 2 (USB, approx. 200 EUR, Community)

Cloud HSM (on-demand, no purchase):
  AWS CloudHSM:           Single-tenant HSM in AWS, FIPS 140-2 Level 3
                          Price: ~$1.50/hour (~€1,000/month)
  Azure Dedicated HSM:    Thales Luna hardware in Azure
  Google Cloud HSM:       Cloud KMS + HSM backend
  Price: significantly cheaper than on-premises for small workloads

---

HSM vs. KMS (Cloud Key Management Service):

  HSM:
  → Physical hardware, single-tenant
  → Maximum security
  → FIPS Level 3: tamper-proof
  → Expensive, complex

  KMS (AWS KMS, Azure Key Vault):
  → Software-based (HSM in the background, multi-tenant)
  → Easier to use, API-first
  → FIPS 140-2 Level 2 (mostly)
  → More affordable: AWS KMS ~$1/month/key + $0.03/10k API calls
  → Sufficient for most use cases!

Recommendation:
  Standard applications:     AWS KMS / Azure Key Vault (simple, affordable, secure)
  High security (PCI HSM): Cloud HSM or on-premises HSM
  Small budget:           Nitrokey HSM (physical) or Vault (software)

Practical Key Management Solutions

HashiCorp Vault - Open Source Key Management:

Installation (Docker):
  docker run -d --name vault \
    -p 8200:8200 \
    -e 'VAULT_DEV_ROOT_TOKEN_ID=mytoken' \
    hashicorp/vault

  export VAULT_ADDR='http://127.0.0.1:8200'
  export VAULT_TOKEN='mytoken'

  vault status

Storing secrets (not key management per se, but secrets):
  vault kv put secret/myapp db_password="secret123"
  vault kv get secret/myapp

Transit Secrets Engine (Encryption as a Service):
  → Application sends data to Vault → Vault encrypts → returns
  → Key in Vault, never in Application
  vault secrets enable transit
  vault write -f transit/keys/myapp-key  # Create key

  # Encrypt:
  vault write transit/encrypt/myapp-key plaintext=$(base64 <<< "sensitive data")
  # Returns: ciphertext: vault:v1:ENCRYPTED...

  # Decrypt:
  vault write transit/decrypt/myapp-key ciphertext="vault:v1:ENCRYPTED..."

  # Automatic rotation:
  vault write transit/keys/myapp-key/config auto_rotate_period=720h

---

AWS KMS (Cloud Key Management):

Create key:
  aws kms create-key \
    --description "Production Database Key" \
    --key-usage ENCRYPT_DECRYPT \
    --origin AWS_KMS \
    --tags TagKey=env,TagValue=production

Encrypt:
  aws kms encrypt \
    --key-id alias/prod-db-key \
    --plaintext fileb://secret.txt \
    --output json | jq -r '.CiphertextBlob' | base64 -d > encrypted.bin

Enable automatic rotation:
  aws kms enable-key-rotation --key-id alias/prod-db-key
  # Rotates automatically annually; old keys remain for decryption!

Key Policy (who is allowed to use the key?):
  {
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": {"AWS": "arn:aws:iam::ACCOUNT:role/AppRole"},
        "Action": ["kms:Decrypt", "kms:GenerateDataKey"],
        "Resource": "*",
        "Condition": {
          "StringEquals": {"aws:RequestedRegion": "eu-central-1"}
        }
      }
    ]
  }

---

Critical Anti-Patterns:
  ✗ Hardcoded keys in code:     myKey = "supersecretkey123"
  ✗ Keys in Git repository:     config.yml containing passwords
  ✗ Keys as environment variables (visible in logs!): KEY=abc123
  ✗ SSH keys never rotated (employee left 5 years ago)
  ✗ Same key for all environments (prod/staging/dev)
  ✗ Symmetric key sent via email

  ✓ Vault / KMS:              Manage keys centrally
  ✓ Service Account:          Application has its own key set
  ✓ Key Hierarchy:            DEK → KEK → HSM master key
  ✓ Audit Log:                Every key access logged
  ✓ Regular rotation:     Automatic, documented
  ✓ Break-glass procedure:    Emergency key securely stored