Schlüsselmanagement - Kryptografische Schlüssel sicher verwalten

Schlüsselmanagement ist die Achillesferse der Kryptographie. Die stärkste Verschlüsselung ist wertlos wenn Schlüssel schlecht generiert, unsicher gespeichert oder nie rotiert werden. “Die Sicherheit eines verschlüsselten Systems hängt nicht von der Mathematik ab - sie hängt von den Schlüsseln ab.”

Schlüssel-Lebenszyklus

Key Management Lifecycle:

Phase 1: Key Generation (Erzeugung)
  → Kryptografisch sichere Zufallszahlen (CSPRNG)
  → Probleme:
    - Schwache Entropy-Quellen (Virtual Machines haben weniger Entropy)
    - Hardware-RNG vs. Software-RNG
  → Linux: /dev/urandom (seit Kernel 5.x: ausreichend)
  → Python: secrets.token_bytes(32)  # Kein: random.random()!
  → Hardware-Empfehlung: HSM generiert Schlüssel intern (verlässt nie!)
  → Schlüsselstärke: AES-256, RSA-4096 (alt) oder ECDSA P-384

Phase 2: Key Distribution (Verteilung)
  → Wie kommt der Schlüssel zum berechtigten Empfänger?
  → Problem: "Key Distribution Problem" - wie teilt man Schlüssel sicher?
  → Asymmetrische Krypto: öffentlichen Schlüssel tauschen → verschlüsselt senden
  → Key Wrapping: Schlüssel mit anderem Schlüssel verschlüsseln
  → Key Escrow: Schlüssel bei vertrauenswürdiger Partei hinterlegen

Phase 3: Key Storage (Speicherung)
  → Schlechteste Praxis: Schlüssel in Konfigurationsdatei (Plaintext!)
  → Mittelmäßig: Verschlüsselt in Datenbank
  → Gut: Key Management Service (AWS KMS, Azure Key Vault, HashiCorp Vault)
  → Optimal: HSM (Hardware Security Module)

Phase 4: Key Rotation (Rotation)
  → Regelmäßige Erneuerung begrenzt Schadensausmaß bei Kompromittierung
  → Empfohlene Rotationsintervalle:
    Datenverschlüsselungsschlüssel (DEK): monatlich (oder pro Datei)
    Schlüsselverschlüsselungsschlüssel (KEK): jährlich
    TLS-Zertifikate: vor Ablauf (min. 90 Tage vor Expiry)
    SSH-Schlüssel: jährlich
    API Keys: jährlich oder bei Mitarbeiterwechsel
  → Automatische Rotation: KMS und Vault können das!

Phase 5: Key Revocation (Widerruf)
  → Kompromittierter Schlüssel muss sofort ungültig werden
  → X.509-Zertifikate: CRL (Certificate Revocation List) oder OCSP
  → OCSP Stapling: Server liefert OCSP-Antwort mit TLS-Handshake

Phase 6: Key Destruction (Vernichtung)
  → Kryptografische Schlüssel sicher löschen!
  → SSD: Standard-Löschen reicht NICHT (Flash-Cells)
  → Sichere Löschung: Crypto-Erase (Schlüssel löschen = Daten unlesbar)
  → HSM: sichere Zeroization (kryptografisches Löschen)
  → Dokumentation: wann, warum gelöscht (Compliance!)

Hardware Security Modules (HSMs)

Was ist ein HSM?

Hardware Security Module:
  → Dedizierte Hardware für kryptografische Operationen
  → Schlüssel verlassen das HSM NIE in unverschlüsselter Form!
  → Tamper-Proof: physische Manipulation → automatische Schlüssellöschung
  → FIPS 140-2/3 Level 3 zertifiziert (höchste Sicherheitsstufe)
  → NSS (Non-Stop Security): aktiv auch wenn angegriffen

Verwendung von HSMs:
  → CA-Stammzertifikate: Root CA Schlüssel in HSM (unveräußerlich!)
  → Datenbankverschlüsselung: Masterschlüssel in HSM
  → Code-Signing: Signierschlüssel in HSM
  → Payment: PCI DSS verlangt HSM für Kartenverschlüsselung
  → Kubernetes/Cloud: Verschlüsselungsschlüssel für etcd im HSM

HSM-Produkte:

On-Premises:
  Thales Luna (SafeNet):  Marktführer, FIPS 140-2 Level 3, ab 20k EUR
  nCipher nShield:        nForce, Connect XC, ab 15k EUR
  Utimaco SecurityServer: Deutsches Unternehmen, BSI-Zulassung
  Micro HSM (für KMU):    Nitrokey HSM 2 (USB, ca. 200 EUR, Community)

Cloud HSM (on-demand, kein Kauf):
  AWS CloudHSM:           Single-Tenant HSM in AWS, FIPS 140-2 Level 3
                          Preis: ~1.50 USD/Stunde (~1000 EUR/Monat)
  Azure Dedicated HSM:    Thales Luna-Hardware in Azure
  Google Cloud HSM:       Cloud KMS + HSM-Backend
  Preis: deutlich günstiger als On-Premises für kleine Workloads

---

HSM vs. KMS (Cloud Key Management Service):

  HSM:
  → Physische Hardware, Single-Tenant
  → Maximale Sicherheit
  → FIPS Level 3: tamper-proof
  → Teuer, komplex

  KMS (AWS KMS, Azure Key Vault):
  → Software-basiert (HSM im Hintergrund, Multi-Tenant)
  → Einfacher zu nutzen, API-first
  → FIPS 140-2 Level 2 (meist)
  → Günstiger: AWS KMS ~1 USD/Monat/Schlüssel + 0.03 USD/10k API calls
  → Für die meisten Anwendungsfälle ausreichend!

Empfehlung:
  Normale Anwendungen:     AWS KMS / Azure Key Vault (einfach, günstig, sicher)
  Hochsicherheit (PCI HSM): Cloud HSM oder On-Premises HSM
  Kleines Budget:           Nitrokey HSM (physisch) oder Vault (Software)

Praktische Key-Management-Lösungen

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

Secrets speichern (kein Schlüsselmanagement per se, aber Secrets):
  vault kv put secret/myapp db_password="secret123"
  vault kv get secret/myapp

Transit Secrets Engine (Encryption as a Service):
  → Application schickt Daten zu Vault → Vault verschlüsselt → gibt zurück
  → Schlüssel in Vault, nie in Application
  vault secrets enable transit
  vault write -f transit/keys/myapp-key  # Schlüssel erstellen

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

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

  # Automatische Rotation:
  vault write transit/keys/myapp-key/config auto_rotate_period=720h

---

AWS KMS (Cloud Key Management):

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

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

Automatische Rotation aktivieren:
  aws kms enable-key-rotation --key-id alias/prod-db-key
  # Rotiert jährlich automatisch, alte Schlüssel bleiben für Entschlüsselung!

Key Policy (wer darf den Schlüssel nutzen?):
  {
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": {"AWS": "arn:aws:iam::ACCOUNT:role/AppRole"},
        "Action": ["kms:Decrypt", "kms:GenerateDataKey"],
        "Resource": "*",
        "Condition": {
          "StringEquals": {"aws:RequestedRegion": "eu-central-1"}
        }
      }
    ]
  }

---

Kritische Anti-Patterns:
  ✗ Hardcoded Keys in Code:     myKey = "supersecretkey123"
  ✗ Keys in Git Repository:     config.yml mit Passwörtern
  ✗ Keys als Environment-Variable (in Logs sichtbar!): KEY=abc123
  ✗ Nie rotierte SSH-Keys (Mitarbeiter seit 5 Jahren ausgeschieden)
  ✗ gleicher Schlüssel für alle Umgebungen (prod/staging/dev)
  ✗ Symmetrischer Schlüssel per E-Mail versandt

  ✓ Vault / KMS:              Schlüssel zentralisiert verwalten
  ✓ Service Account:          Application hat eigenen Schlüsselsatz
  ✓ Key Hierarchy:            DEK → KEK → HSM-Masterkey
  ✓ Audit Log:                jeder Schlüsselzugriff geloggt
  ✓ Regelmäßige Rotation:     automatisch, dokumentiert
  ✓ Break-Glass-Verfahren:    Notfall-Schlüssel sicher verwahrt