Cryptographic Agility - Kryptografische Agilität

Cryptographic Agility ist kein neues Konzept - aber selten konsequent umgesetzt. Die SHA-1-Ablösung dauerte über ein Jahrzehnt weil Systeme SHA-1 hartcodiert hatten. Die MD5-Ablösung dauerte noch länger. Jetzt kommt die größte kryptografische Migration in der IT-Geschichte: Post-Quantum-Kryptografie. Systeme ohne kryptografische Agilität werden wieder Jahre brauchen. Agile Systeme wechseln Algorithmen in Wochen.

Warum Cryptographic Agility wichtig ist

Historische Algorithmus-Ablösungen (wie lange dauerte es?):

MD5 (1991 → unsicher seit 2004):
  2004: Kollisionsangriff publiziert (Wang/Yu)
  2008: Flame-Malware nutzt MD5-Schwäche für Code-Signing-Fälschung
  2012: BSI: MD5 für digitale Signaturen ungeeignet
  2024: MD5 noch in vielen Legacy-Systemen aktiv!
  → 20+ Jahre Migration, immer noch nicht abgeschlossen

SHA-1 (1995 → unsicher seit 2005):
  2005: Theoretischer Angriff publiziert (Wang)
  2011: NIST: SHA-1 für Signaturen nach 2013 nicht mehr erlaubt
  2017: SHAttered - Google zeigt erste SHA-1-Kollision praktisch
  2023: SHA-1 noch in Netzwerkgeräten, Legacy-Protokollen aktiv
  → 18 Jahre und immer noch in Betrieb

RSA 1024 bit:
  2010: NIST: RSA-1024 für Signaturen depreciert
  2015: Deadline abgelaufen
  2026: Noch in IoT-Geräten, eingebetteten Systemen verbreitet

Post-Quantum (2024 → Migration läuft):
  2024: NIST FIPS 203/204/205 verabschiedet (ML-KEM, ML-DSA, SLH-DSA)
  2030: Quantencomputer (relevante Größe) möglicherweise verfügbar
  2026-2030: Kritisches Zeitfenster für Migration
  → Systeme OHNE Kryptografische Agilität werden wieder 15+ Jahre brauchen!

Fazit: Kryptografische Agilität ist nicht optional - sie entscheidet
über die Überlebensfähigkeit eines Systems in der PQC-Ära.

Architekturmuster für Cryptographic Agility

Pattern 1: Algorithmus-Abstraktion (Code-Ebene)

  SCHLECHT - Algorithmus hartcodiert:
  # Python:
  import hashlib
  hash = hashlib.sha256(data).hexdigest()  # Was wenn SHA-256 unsicher wird?

  BESSER - Abstraktion mit Austauschbarkeit:
  # Python:
  HASH_ALGORITHM = os.getenv("HASH_ALGORITHM", "sha256")

  def hash_data(data: bytes, algorithm: str = HASH_ALGORITHM) -> str:
      h = hashlib.new(algorithm)
      h.update(data)
      return h.hexdigest()

  # Wechsel zu SHA-3: ENV-Variable ändern → keine Code-Änderung!
  HASH_ALGORITHM=sha3_256 → Sofort aktiv

Pattern 2: Cryptographic Provider Interface

  # Java - Provider-Muster:
  public interface CryptoProvider {
      byte[] encrypt(byte[] plaintext, byte[] key);
      byte[] decrypt(byte[] ciphertext, byte[] key);
      String getAlgorithmId();
  }

  public class AES256GCMProvider implements CryptoProvider {
      @Override public byte[] encrypt(byte[] plaintext, byte[] key) { ... }
      @Override public String getAlgorithmId() { return "AES-256-GCM"; }
  }

  public class ML_KEMProvider implements CryptoProvider {
      @Override public byte[] encrypt(byte[] plaintext, byte[] key) { ... }
      @Override public String getAlgorithmId() { return "ML-KEM-768"; }
  }

  // Wechsel: CryptoProvider provider = new ML_KEMProvider();
  // Rest des Codes unverändert!

Pattern 3: Algorithm Negotiation (TLS-Stil)

  Client → Server: "Ich unterstütze: AES-256-GCM, ChaCha20-Poly1305, ML-KEM"
  Server: "Ich unterstütze: AES-256-GCM, ML-KEM"
  Einigung: "ML-KEM" (beste gemeinsame Unterstützung)

  → TLS 1.3: genau dieses Prinzip!
  → TLS Ciphersuites: server-side konfigurierbar ohne Clientänderung

Pattern 4: Key Versioning

  # Schlüssel und Algorithmus immer gemeinsam versionen:
  {
    "key_id": "k2026-03",
    "algorithm": "ML-KEM-768",
    "created": "2026-03-01",
    "expires": "2027-03-01",
    "key_material": "<encrypted-key>"
  }

  # Alte verschlüsselte Daten: mit altem Key + altem Algorithmus entschlüsseln
  # Neue Daten: mit neuem Key + neuem Algorithmus verschlüsseln
  # Kein Big Bang Migration nötig!

TLS-Konfiguration für Cryptographic Agility

Nginx - zukunftssichere TLS-Konfiguration:

ssl_protocols TLSv1.2 TLSv1.3;
# TLS 1.3 priorisieren - sicherer, schneller

ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-RSA-AES256-GCM-SHA384;
# TLS 1.3 Ciphers zuerst, dann TLS 1.2 Fallback

ssl_prefer_server_ciphers on;
# Server entscheidet (wichtig für Agility!)

# Post-Quantum TLS (experimentell, OpenSSL 3.5+):
# ssl_ciphers X25519Kyber768Draft00:TLS_AES_256_GCM_SHA384;
# → Hybrid: klassisch + PQ kombiniert

OpenSSL 3.x Provider-System:
  # Algorithmen als loadbare Provider:
  openssl list -providers
  # Default Provider (klassisch) + FIPS Provider + OQS Provider (Post-Quantum)

  # OQS (Open Quantum Safe) Provider laden:
  openssl speed -provider oqsprovider ml-kem-768
  # Testet ML-KEM-768 Performance

Crypto Policy in RHEL/Fedora:
  # System-weite Kryptografie-Policy:
  update-crypto-policies --set FIPS
  update-crypto-policies --set FUTURE  # Strengere Algorithmen
  # Ändert TLS-Defaults für alle Anwendungen systemweit
  # Keine App-by-App-Anpassung nötig!

Java Security Properties (JVM-weit):
  # $JAVA_HOME/conf/security/java.security
  jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, ...
  jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1, DSA, ...
  # Systemweit für alle Java-Anwendungen - ein Ort, alle Apps

Hybrid Cryptography für PQC-Migration

Hybrid-Ansatz: Klassisch + Post-Quantum parallel (Empfehlung während Übergangszeit):

Warum Hybrid?
  → PQC-Algorithmen sind neu: Implementierungsfehler möglich
  → Klassische Kryptografie: bewährt, aber Quantum-gefährdet
  → Hybrid: beide sicher = Kombination sicher
  → BSI-Empfehlung: Hybrid bis PQC reif genug

TLS 1.3 Hybrid Key Exchange:
  # RFC 9370: Multiple Key Shares in TLS
  # OpenSSL 3.5+ (experimentell):
  Client Hello: key_share = [X25519 || ML-KEM-768]
  Server Hello: key_share = [X25519 || ML-KEM-768]
  # Session Key = SHA256(X25519_shared_secret || ML-KEM_shared_secret)
  # Quantencomputer muss BEIDES brechen → sicher!

SSH Hybrid (OpenSSH 9.0+):
  # /etc/ssh/sshd_config
  KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256
  # sntrup761 (PQ) + x25519 (klassisch) hybrid

Signal Protocol (Messenger):
  → PQXDH: Post-Quantum Extended Diffie-Hellman
  → Ersetzt X3DH durch Hybrid (ML-KEM + X25519)
  → Implementiert seit Signal 2024

Signaturschemen:
  # Hybride Zertifikate (RFC in Entwicklung):
  # 1 Zertifikat mit 2 Schlüsselpaaren: RSA-4096 + ML-DSA-87
  # Signature: RSA_sign(ML-DSA_sign(message))
  # Beide müssen brechen - weder RSA noch ML-DSA allein reicht

Migration-Roadmap für Cryptographic Agility:

  2024-2025: Inventarisierung
    □ Crypto-Inventur: wo wird welcher Algorithmus genutzt?
    □ Alle APIs, Protokolle, Zertifikate, Key-Stores erfassen
    □ "Crypto Bill of Materials" erstellen

  2025-2027: Hybrid-Deployment
    □ TLS: Hybrid Key Exchange aktivieren (wo unterstützt)
    □ Code-Refactoring: Algorithmen abstrahieren
    □ Key Management: Versionierung einführen

  2027-2030: PQC-Migration
    □ Zertifikate: schrittweise zu ML-DSA wechseln
    □ Key Exchange: vollständig PQC (nach Hybrid-Phase)
    □ Long-lived Daten: Re-Encryption mit PQC-Schlüsseln

  2030+: Klassische Kryptografie deprecieren
    □ RSA, ECC für kritische Systeme abschalten
    □ AES-256/ChaCha20 bleiben (symmetrisch Quantum-sicher mit 128+ bit!)