Krypto-Agilität: Definition und Umsetzung in Systemen

Krypto-Agilität ist die Fähigkeit eines Systems, seine kryptografischen Algorithmen, Parameter und Schlüssel zu wechseln, ohne Anwendungscode neu zu schreiben und ohne auf ein neues Produktrelease zu warten. Sie ist keine Funktion, die man kauft, sondern eine Reihe technischer Eigenschaften: vor allem Konfiguration statt fest codierter Entscheidungen, Aushandlung auf Protokollebene, ein aktuelles Inventar, saubere Abstraktionsgrenzen sowie automatisierte Lebenszyklen für Schlüssel und Zertifikate. Aufsichtsbehörden beschreiben dieselbe Fähigkeit inzwischen mit eigenen Worten. So verlangen die technischen Standards zu DORA eine Verschlüsselungsrichtlinie mit Bestimmungen zur Änderung kryptografischer Technologie entsprechend den Entwicklungen in der Kryptoanalyse.

Was Krypto-Agilität bedeutet

Eine brauchbare Arbeitsdefinition: Ein System ist kryptografisch agil, wenn ein kompetenter Betreiber einen Algorithmus, eine Schlüssellänge oder eine Protokollversion in einem kontrollierten Änderungsfenster austauschen kann, und zwar mit bereits vorhandener Konfiguration und Automatisierung, und anschließend nachweisen kann, was nun im Einsatz ist. Der Test ist operativ, nicht theoretisch. Wenn der Wechsel einer Schlüsselaustauschgruppe bedeutet, Quellcode zu ändern, ein Container-Image neu zu bauen, mit einem Anbieter neu zu verhandeln oder undokumentierte Abhängigkeiten zu entdecken, ist das System nicht agil, was auch immer seine Dokumentation behauptet.

Drei Unterscheidungen sollten Sie festhalten:

• Agilität ist nicht dasselbe wie Post-Quanten-Bereitschaft. Post-Quanten-Kryptografie (PQC) ist ein Ziel. Agilität ist das Fahrzeug. Ein Server, der heute einen hybriden Post-Quanten-Schlüsselaustausch anbietet, ihn aber nächstes Jahr nicht ändern kann, hat eine Migration gelöst und sich auf keine weitere vorbereitet.
• Agilität ist nicht nur Aushandlung. Transport Layer Security (TLS) handelt aus. Gespeicherte Datenformate, signierte Firmware, Hardware-Sicherheitsmodule, Zahlungsterminals und eingebettete Geräte tun das oft nicht. Dort muss Agilität konzipiert statt konfiguriert werden.
• Agilität hat eine Rangfolge. Harvest now, decrypt later (HNDL) beschreibt aufgezeichneten Datenverkehr, den ein Angreifer aufbewahrt, bis eine Entschlüsselung möglich wird. Aufgezeichnete Sitzungen sind nur durch den Schlüsselaustausch geschützt. Deshalb wird zuerst die Schlüsselvereinbarung migriert, Signaturen können folgen. Unser Artikel zu Harvest now, decrypt later erläutert diese Reihenfolge im Detail.

Konfiguration statt Code, Aushandlung statt fester Codierung

Die erste Eigenschaft: Die Algorithmusauswahl liegt in einer Konfiguration, die ein Betreiber verantwortet, an einer Stelle pro Host oder pro Dienst, und wird wie jede andere Kontrolle geprüft. Eine zentrale kryptografische Richtlinie ist anwendungsspezifischen Schaltern überlegen, denn genau solche Schalter geraten in Vergessenheit.

TLS: benannte Gruppen und eine geordnete Präferenzliste

In TLS 1.3 ist der Schlüsselaustausch eine benannte Gruppe, die pro Verbindung ausgehandelt wird. Das Register der Internet Assigned Numbers Authority (IANA) führt die hybriden Gruppen X25519MLKEM768 (Codepoint 0x11EC), SecP256r1MLKEM768 (0x11EB) und SecP384r1MLKEM1024 (0x11ED) neben den reinen ML-KEM-Gruppen (IANA TLS parameters). ML-KEM ist der Schlüsselkapselungsmechanismus (KEM), den NIST am 13. August 2024 in FIPS 203 standardisiert hat. RFC 10024 (August 2026) spezifiziert die hybride Schlüsselvereinbarung aus Post-Quanten- und klassischen Verfahren für TLS 1.3.

Eine agile Konfiguration legt eine geordnete Präferenz fest und behält einen klassischen Fallback bei, sodass sich ein Client, der die hybride Gruppe nicht unterstützt, trotzdem verbindet. Für die ML-KEM-Gruppen ist OpenSSL 3.5 oder neuer erforderlich:

# /etc/ssl/openssl.cnf (OpenSSL 3.5 or later)
openssl_conf = default_conf

[default_conf]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
Groups = X25519MLKEM768:X25519:P-256
MinProtocol = TLSv1.2

Prüfen Sie vor und nach jeder Änderung von außen, mit einem rein lesenden Test:

# read-only test: does the server accept the hybrid group?
openssl s_client -groups X25519MLKEM768 -connect example.com:443 < /dev/null 2>/dev/null | grep -i 'Negotiated TLS1.3 group'

Auf Webserver-Ebene ist dieselbe Präferenz eine einzige Direktive, zum Beispiel ssl_ecdh_curve X25519MLKEM768:X25519; in nginx, gebaut gegen eine geeignete OpenSSL-Version. Unsere Anleitung zum Aktivieren von ML-KEM in nginx, Apache, HAProxy und Caddy nennt die Syntax pro Produkt und die Mindestversionen. Testen Sie zuerst in Staging und behalten Sie die Fallback-Gruppe bei.

SSH: dasselbe Muster, bereits ausgeliefert

OpenSSH ist ein gutes Beispiel für gelebte Agilität. Version 9.0 (8. April 2022) machte einen hybriden Schlüsselaustausch zum Standard. Version 9.9 (19. September 2024) fügte mlkem768x25519-sha256 hinzu. Version 10.0 (9. April 2025) machte es zur Standard-Schlüsselvereinbarung, und 10.1 (6. Oktober 2025) warnt über das standardmäßig aktivierte WarnWeakCrypto, wenn eine Verbindung eine Schlüsselvereinbarung ohne Post-Quanten-Schutz aushandelt (OpenSSH Release Notes). Betreiber, die ihre Präferenzen in der Konfiguration ausgedrückt hatten, übernahmen die Änderung automatisch. Wer einen einzelnen Algorithmus in Skripten fest verankert hatte, nicht.

# list what this client supports, then set an ordered preference
ssh -Q kex

# /etc/ssh/sshd_config (OpenSSH 9.9 or later), classical fallback last
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com,curve25519-sha256

Inventar, Abstraktion und Automatisierung

Ein abfragbares Inventar, keine Tabelle, die man ständig neu schreibt

Was Sie nicht auflisten können, können Sie nicht ändern. Ein Inventar rechtfertigt seinen Aufwand, wenn es eine Frage in Minuten beantwortet: Welche Dienste handeln noch einen rein klassischen Schlüsselaustausch aus, welche Zertifikate verwenden welchen Signaturalgorithmus, welche Bibliotheken stellen die Primitive bereit, und wer ist jeweils verantwortlich? Erfassen Sie mindestens das Asset, Protokoll und Version, Algorithmen und Schlüssellängen, den Zweck, den Verantwortlichen, die Version der Bibliothek oder des Moduls sowie den Erneuerungsmechanismus. Eine kryptografische Stückliste (CBOM) ist eine maschinenlesbare Form dafür; siehe was eine CBOM ist. Betrachten Sie die CBOM als von uns empfohlene Praxis, nicht als gesetzliche Anforderung.

Abstraktionsschichten, die den Algorithmus verbergen

Anwendungscode sollte eine Fähigkeit anfordern, keinen Namen. Vier Muster bringen den größten Teil des Nutzens:

• Aufrufe über einen Provider oder eine schlanke interne Bibliothek. Ein Modul übersetzt die Richtlinie in Primitive, sodass sich eine einzige Änderung überall auswirkt.
• Jedes gespeicherte Format versionieren. Versehen Sie Chiffrate, Token und signierte Umschläge mit einem Algorithmusbezeichner und einer Formatversion als Präfix, damit alte Daten lesbar bleiben, während neue Daten den neuen Algorithmus verwenden.
• Niemals Größen voraussetzen. Öffentliche Schlüssel und Chiffrate von ML-KEM sowie Signaturen von ML-DSA sind deutlich größer als ihre Entsprechungen auf Basis elliptischer Kurven. Datenbankspalten fester Länge, feste Puffer, Obergrenzen für Nachrichtengrößen und Protokollfelder, die für 32-Byte-Schlüssel ausgelegt sind, sind das häufigste harte Hindernis. Bevorzugen Sie Felder mit Längenpräfix.
• Einen doppelten Verifikationspfad beibehalten. Akzeptieren und prüfen Sie während der Übergangsphase sowohl den alten als auch den neuen Algorithmus und entfernen Sie den alten dann nach einem terminierten Plan.

Schlüssel und Zertifikate, die ohne manuelles Eingreifen rotieren

Eine Rotation, die Sie einmal im Jahr von Hand durchführen, ist keine Kontrolle, sondern eine Generalprobe, die scheitern wird. Automatisierte Ausstellung und Erneuerung, kurze Zertifikatslaufzeiten und eine Warnung bei nicht erneuerten Zertifikaten machen einen Algorithmuswechsel zur Routine: Ändert sich der Signaturalgorithmus, stellt die Pipeline einfach andere Zertifikate aus. Rotationsübungen gehören in den Änderungskalender. Zustandsbehaftete hashbasierte Signaturen (LMS und XMSS, standardisiert in NIST SP 800-208) sind die Ausnahme, die die Regel bestätigt: Ihre Zustandsverwaltung macht ein naives Duplizieren eines Signaturschlüssels unsicher, daher erfordern sie ein bewusstes Schlüsselmanagement statt generischer Automatisierung.

Wo Regulierung Agilität verlangt und welche Nachweise passen

Mehrere Texte verlangen diese Fähigkeit, ohne den Begriff zu verwenden. Die Tabelle trennt, was der jeweilige Text wörtlich sagt, von unserem Vorschlag für den Nachweis. Dies ist eine Information und keine Rechtsberatung: Klären Sie Ihre eigenen Pflichten mit Ihrer Rechtsberatung oder Ihrer Aufsichtsbehörde.

Lesen Sie den genauen Wortlaut in der Verordnung (EU) 2024/1774 und sehen Sie sich unsere Seiten zu DORA und PCI DSS v4.0.1 für die datierten Meilensteine an. Halten Sie die Verbindlichkeitsgrade auseinander: Die EU Coordinated Implementation Roadmap v1.1 ist eine koordinierte Orientierungshilfe für die Mitgliedstaaten und keine für Unternehmen verbindliche Verordnung, BSI TR-02102-1 ist eine Technische Richtlinie, ANSSI erklärt, dass ihre Post-Quanten-Empfehlungen außerhalb ihres regulierten Bereichs noch keine regulatorischen Pflichten sind, und NIST IR 8547 ist weiterhin ein erster öffentlicher Entwurf.

Fallstricke, die Agilität unbemerkt untergraben

• Einen einzelnen Algorithmus in Code oder Skripten fest verankern, statt eine geordnete Präferenz in der Konfiguration auszudrücken.
• Den klassischen Fallback zu früh entfernen. Behalten Sie X25519 nach X25519MLKEM768 bei, bis Ihre Client-Population vermessen ist.
• Veraltete vorstandardisierte Gruppen beibehalten. Die TLS-Gruppen aus dem Kyber-Entwurf sind veraltet: Wechseln Sie zu X25519MLKEM768 und den anderen registrierten Hybridverfahren.
• Ein Inventar ohne Verantwortliche. Eine Liste, für die niemand zuständig ist, bewirkt keine Veränderung.
• Langlebige Artefakte vergessen: Signierte Firmware, Dokumentsignaturen, Backups und archivierte Daten überdauern die Systeme, die sie erzeugt haben.

Messen Sie, was Ihre Systeme heute aushandeln

Agilität beginnt mit einer ehrlichen Ausgangsbasis, und deren von außen sichtbarer Teil ist schnell ermittelt: Scannen Sie Ihre Domain mit PQC Status, um zu sehen, welche TLS-Versionen, Cipher Suites, Schlüsselaustauschgruppen und Zertifikatsalgorithmen Ihr Server tatsächlich aushandelt. Ein Scan beschreibt ausschließlich die von außen sichtbare TLS-Konfiguration: Er ist weder eine Zertifizierung noch eine Konformitätsbestätigung, wie unsere Methodik-Seite erläutert. Der konkrete nächste Schritt: Nehmen Sie dieses Ergebnis, erfassen Sie jeden Dienst mit einem Verantwortlichen in Ihrem kryptografischen Inventar, verlagern Sie dann die Algorithmusauswahl für einen Dienst in die zentrale Konfiguration und proben Sie die Änderung in Staging.