Krypto-Agilität in der Praxis: Kryptographie von der Geschäftslogik abstrahieren

Bitten Sie ein Entwicklerteam, einen Verschlüsselungsalgorithmus zu ändern, und beobachten Sie, wie aus einer einfachen Entscheidung ein sechsmonatiges Projekt wird. Der Algorithmus selbst ist selten das Schwierigste. Die Schwierigkeit liegt vielmehr darin, dass der Algorithmus nicht zentral definiert ist. Er ist in Hunderten von Quelldateien explizit benannt, in gespeicherten Datenformaten eingefroren, in Protokoll-Handshakes integriert und wird stillschweigend von Diensten übernommen, die seit Jahren kein Mitglied des aktuellen Teams mehr genutzt hat. Das sind die wahren Kosten fest codierter Kryptografie, und deshalb bereitet die Migration nach der Quantencomputer-Ära jedem, der versucht hat, sie realistisch einzuschätzen, so große Sorgen.

Krypto-Agilität ist der Schlüssel, und sie ist eine architektonische Eigenschaft, die man einplant, kein Produkt, das man kauft. Gelingt es einmal, und die nächste Algorithmusänderung – sei es nach der Quantenphysik oder als Reaktion auf einen noch unvorhergesehenen Einbruch – erfordert keine komplette Neuentwicklung mehr.

Was ist Krypto-Agilität?

Krypto-Agilität ist die architektonische Eigenschaft, kryptografische Algorithmen, Schlüssel und Parameter ersetzen zu können, ohne die darauf basierende Anwendungslogik neu schreiben zu müssen. Dies wird erreicht, indem kryptografische Funktionen hinter einer Serviceschicht oder API abstrahiert werden.

Anwendungen nutzen eine einheitliche Schnittstelle, während der zugrundeliegende Algorithmus, der Schlüssel und die Parameter durch Konfiguration und nicht durch Codeänderungen angepasst werden. Diese Modularität macht die Migration nach der Quantenintegration und jede zukünftige Algorithmusänderung zu einer Konfigurations- und Testaufgabe anstatt zu einer kompletten Neuentwicklung.

Wichtige Erkenntnisse

• Crypto-Agility trennt kryptografische Operationen durch eine Abstraktionsschicht vom Anwendungscode.
• Anwendungen rufen eine einheitliche API auf, und Algorithmen ändern sich durch Konfiguration, nicht durch Code-Neuschreibungen.
• Ein aktuelles kryptografisches Inventar (CBOM) ist Voraussetzung. Man kann nicht abstrahieren, was man nicht finden kann.
• Hybride Implementierungen, die klassische und Post-Quanten-Kryptographie gleichzeitig ausführen, sind wesentlich einfacher, wenn die Kryptographie bereits abstrahiert ist.
• Krypto-Agilität ist ein Gestaltungsprinzip, das sich bei jedem zukünftigen Übergang auszahlt, nicht nur beim Wechsel zu PQC.

Warum Krypto-Agilität jetzt wichtig ist

Fest codierte Kryptografie ist der Hauptgrund für langsame und kostenintensive Migrationen. Wenn eine Anwendung RSA-2048 direkt verwendet, die Schlüssellänge direkt festlegt und ein bestimmtes Ausgabeformat voraussetzt, ist der Algorithmus keine Option mehr. Er ist eine strukturelle Annahme, die fest im Code, den Daten und den Verträgen zwischen den Diensten verankert ist. Eine Änderung erfordert die gleichzeitige Anpassung all dieser Komponenten und einen Regressionstest.

Der Zeitpunkt macht dies dringlich. Der Entwurf IR 8547 des NIST schlägt vor, RSA und elliptische Kurvenkryptographie nach 2030 abzuschaffen, die Executive Order 14412 setzt bundesweite Fristen für die Zeit nach der Quantencomputertechnologie für 2030 und 2031 fest, und der EU-Rahmen geht in die gleiche Richtung.

Der Begriff „Krypto-Agilität“ hat sich von einem Schlagwort zu einem konkreten Konzept entwickelt: Im Dezember 2025 veröffentlichte das NIST das Cybersecurity White Paper 39 mit dem Titel „Considerations for Achieving Cryptographic Agility“, in dem Krypto-Agilität als die Fähigkeit definiert wird, kryptografische Algorithmen über Protokolle, Anwendungen, Software, Hardware, Firmware und Infrastruktur hinweg zu ersetzen und anzupassen, während gleichzeitig Sicherheit und Betrieb gewährleistet werden.

Und das ist noch nicht die letzte Migration. Im März 2025 wählte das NIST HQC, einen codebasierten Algorithmus, der auf einer anderen mathematischen Grundlage als das gitterbasierte ML-KEM beruht , als Backup-Schlüsselkapselungsmechanismus für den Fall, dass ML-KEM jemals gebrochen werden sollte. Ein Entwurf wird um 2026 erwartet, der endgültige Standard im Jahr 2027.

Ein vierter Signaturstandard, FN-DSA basierend auf Falcon, ist als FIPS 206 in Vorbereitung. Anders ausgedrückt: Die Normungsorganisation signalisiert bereits, dass ein erneuter Algorithmuswechsel notwendig sein wird. Organisationen, die die Migration nach der Quantencomputer-Ära als einmalige Notfallmaßnahme betrachten, werden beim nächsten grundlegenden Wandel wieder am selben, schmerzhaften Ausgangspunkt stehen. Krypto-Agilität verhindert, dass sich diese Notfallmaßnahme wiederholt.

Der Algorithmus selbst ist nie der schwierige Teil. Die eigentliche Herausforderung besteht darin, alle Stellen zu finden, an denen der alte Algorithmus implementiert ist, und ihn zu ändern, ohne etwas anderes zu beschädigen.

Wie eine kryptografische Abstraktionsschicht funktioniert

Eine kryptografische Abstraktionsschicht ist eine Softwareschnittstelle zwischen Ihren Geschäftsanwendungen und den Anbietern kryptografischer Algorithmen – den Bibliotheken, HSMs und Schlüsselverwaltungssystemen, die die eigentlichen Berechnungen durchführen. Anstatt einen spezifischen Algorithmus aufzurufen, fordert eine Anwendung die Schicht auf, Daten zu verschlüsseln, zu signieren oder zu verifizieren. Die Schicht entscheidet dann anhand ihrer aktuellen Konfiguration, wie dies geschieht.

In der Praxis kommuniziert die Anwendung über eine REST-Schnittstelle oder eine Clientbibliothek mit der Schicht. Sie gibt im Prinzip an, diese Nutzdaten für diesen Zweck zu verschlüsseln, nicht mit RSA-2048. Die Schicht ordnet diese Anfrage dem konfigurierten Algorithmus, Schlüssel und den Parametern zu, leitet sie an den richtigen Anbieter weiter und gibt das Ergebnis zurück. Die Wahl des Algorithmus und der Schlüssellänge erfolgt zentral, sodass eine Änderung ein operativer Eingriff und kein Entwicklungsschritt ist. Das Muster entspricht dem Prinzip einer Datenbankabstraktion oder eines Zahlungsgateways: Der Aufrufer gibt seine Absicht an, und die Implementierung kann im Hintergrund flexibel angepasst werden.

Die Komponenten einer krypto-agilen Architektur

Eine krypto-agile Architektur besteht aus mehr als einer API. Sechs Komponenten müssen vorhanden sein, damit sie einer realen Migration standhält:

• Abstraktion kryptografischer Funktionen von der Geschäftslogik: Anwendungen drücken Absichten aus und nennen niemals direkt einen Algorithmus.
• Zentrale Konfiguration von Algorithmen und Parametern: Algorithmus, Schlüssellänge und Modus werden an einer zentralen Stelle festgelegt und nicht über den gesamten Code verstreut.
• Unterstützung mehrerer Algorithmen gleichzeitig: Die parallele Ausführung mehrerer Algorithmen ermöglicht Hybridmodi und schnelle Rollbacks.
• Automatisierte Schlüssel- und Zertifikatsverwaltung: Schlüssel und Zertifikate werden ohne manuelle Choreografie ausgegeben, ausgetauscht und außer Dienst gestellt.
• Ein umfassendes kryptografisches Inventar, das das System speist: Die Ebene kann nur das steuern, was das Inventar bereits erfasst hat.
• Definierte Aktualisierungs- und Rollback-Prozeduren: Die Änderung eines Algorithmus ist ein kontrollierter, reversibler Vorgang mit einem getesteten Rückweg.

Implementierungsmuster und Abwägungen

Es gibt keine allgemeingültige, richtige Form für die Schicht. Das passende Muster hängt davon ab, wie Ihre Systeme aufgebaut sind und wie viel von Ihrem Grundstück Sie realistischerweise bearbeiten können.

Schnittmuster	So funktioniert’s	Hauptkompromisse
Kryptodienst oder API-Gateway	Anwendungen rufen über REST einen zentralen Dienst auf; dieser führt die Operation mit dem konfigurierten Algorithmus und Schlüssel aus.	Ein Netzwerk-Hop erhöht die Latenz, und der Dienst muss hochverfügbar sein.
Clientbibliothek oder SDK	Eine in jede App eingebundene gemeinsame Bibliothek stellt eine stabile Schnittstelle bereit; der Algorithmus wird durch Konfiguration ausgewählt.	Änderungen erfordern eine erneute Bereitstellung oder ein erneutes Laden, und es muss verhindert werden, dass Teams dies umgehen.
Broker vor HSM oder KMS	Ein Broker fungiert als Bindeglied zwischen den Hardwareanbietern und stellt eine einheitliche Schnittstelle für alle diese Anbieter bereit.	Eine weitere operative Ebene, die betrieben werden muss, mit wichtigen Verwahrungs- und Zugriffsrichtlinien, die streng geregelt werden müssen.
Stellvertreter für Altsysteme	Ein Gateway beendet und verschlüsselt den Datenverkehr für Systeme, die nicht verändert werden können, erneut.	Die Abdeckung ist lückenhaft; die interne Kryptografie der Legacy-Anwendung bleibt undurchsichtig.

Jedes Muster birgt die gleichen Kompromisse, die bei der Gestaltung berücksichtigt werden müssen: zusätzliche Latenz auf dem kryptografischen Pfad, das Risiko, einen Single Point of Failure zu schaffen, der nun auf hohe Verfügbarkeit ausgelegt sein muss, der Verwaltungsaufwand einer zentral gesteuerten Funktion und die tatsächliche Schwierigkeit, Legacy-Anwendungen nachträglich anzupassen, die nie für die Delegierung von Kryptographie konzipiert wurden.

Seien Sie hinsichtlich des Umfangs realistisch. Bei einem großen Datenbestand ist die vollständige Datenextraktion ein mehrjähriges Projekt, kein Quartalsprojekt. Beginnen Sie mit den Systemen mit dem höchsten Risiko, also jenen, die Daten mit der längsten Vertraulichkeitsdauer schützen – diese sollten in Ihrem Inventar bereits gekennzeichnet sein – und erweitern Sie das Projekt von dort aus.

Die Normen und die Werkzeuge haben aufgeholt.

Jahrelang lautete der berechtigte Einwand gegen die Post-Quanten-Planung, dass die Algorithmen nicht standardisiert und von den gängigen Bibliotheken nicht unterstützt würden. Beide Argumente verlieren 2024 bzw. 2025 ihre Gültigkeit.

Das NIST finalisierte ML-KEM (FIPS 203), ML-DSA (FIPS 204) und SLH-DSA (FIPS 205) im August 2024, und die gängigen Anbieter, an die Ihre Abstraktionsschicht weitergeleitet wird, haben diese bereits implementiert. OpenSSL 3.5, eine Version mit Langzeitunterstützung, enthält nativ ML-KEM, ML-DSA und SLH-DSA und verwendet standardmäßig den Hybrid-Schlüsselaustausch X25519MLKEM768 für TLS 1.3.

OpenSSH hat einen hybriden ML-KEM-Schlüsselaustausch (mlkem768x25519-sha256) eingeführt, und Red Hat Enterprise Linux 10 aktiviert Post-Quanten-Kryptografie standardmäßig. Am Netzwerkrand übertragen Chrome und Cloudflare bereits einen wachsenden Anteil des TLS- Datenverkehrs über denselben hybriden Schlüsselaustausch aus X25519 und ML-KEM-768.

Die kryptografischen Grundbausteine ​​sind nicht länger der Flaschenhals. Bibliotheken und Standards sind vorhanden. Was den meisten Organisationen fehlt, ist die Schicht, die es ihnen ermöglicht, die bereits von den Anbietern unterstützten Funktionen zu nutzen. Genau hier liegt der entscheidende Vorteil in der Krypto-Agilität. Die Anbieter unterhalb einer Abstraktionsschicht sprechen nun nativ Post-Quanten-Verschlüsselung. Der Unterschied zwischen einer Organisation, die innerhalb eines Testzyklus migriert, und einer, die die Migration über Jahre hinweg vorantreibt, liegt also darin, ob die Kryptografie von Anfang an abstrahiert wurde.

Wie Crypto-Agility die PQC-Migration unterstützt

Hier amortisiert sich die Investition. Dank einer bereits vorhandenen Abstraktionsschicht und Anbietern, die die Standards bereits implementieren, wird der Umstieg auf ML-KEM und ML-DSA oder auf die standardisierte Hybridgruppe X25519MLKEM768, die das klassische X25519 mit ML-KEM-768 kombiniert, zu einer Konfigurations- und Testaufgabe anstatt einer kompletten Neuentwicklung. Sie aktivieren die neue Gruppe in den Einstellungen, führen sie im Hybridmodus parallel zur klassischen Gruppe aus, sodass eine Schwachstelle in einer der beiden Gruppen die Sitzung nicht unterbrechen kann, validieren Verhalten und Leistung und geben sie erst frei, wenn Sie zufrieden sind.

Der hybride Ansatz ist auch der konservative, da er einen bewährten klassischen Algorithmus beibehält, während die Post-Quanten-Algorithmen Erfahrungen in der Praxis sammeln.

Genauso wichtig ist es, einen erprobten Rückweg zu haben. Sollte sich ein Post-Quanten-Algorithmus oder ein Parametersatz als überarbeitungsbedürftig erweisen, ist ein Rollback lediglich eine Konfigurationsänderung und keine Notfall-Neuinstallation für Hunderte von Diensten. Die gleichen Mechanismen, die Sie in die Post-Quanten-Kryptographie führen, helfen Ihnen auch bei allem, was danach kommt.

Mit der vorhandenen Abstraktion lässt sich die Post-Quanten-Migration konfigurieren und testen. Ohne sie muss sie komplett neu aufgebaut werden.

Wie Verschlüsselungsberatung hilft

Crypto-Agilität ist ein Programm mit drei dynamischen Komponenten, die von Encryption Consulting abgedeckt werden. PQC Advisory entwickelt die Agilitäts-Roadmap, wählt das passende Abstraktionsmuster für Ihre Architektur und sequenziert die Implementierung von den Systemen mit dem höchsten Risiko nach außen. CBOM Secure erstellt und pflegt das kryptografische Inventar, auf dem die Abstraktionsschicht basiert, denn man kann nicht abstrahieren, was man nicht gefunden hat. CBOM Secure hält dieses Inventar bei Änderungen der Systemlandschaft stets aktuell. HSM- und Schlüsselverwaltungsdienste bilden die darunterliegende Provider-Schicht, sodass die von dieser Schicht verwendeten Algorithmen durch eine sichere Schlüsselverwaltung geschützt sind.

Die Reihenfolge ändert sich selten: Zuerst die Kryptographie finden, dann abstrahieren und anschließend jede Migration von der Schicht zu einer Einstellung und nicht zu einem Projekt machen lassen.

Rufen Sie uns an

Sprechen Sie mit einem PQC-Berater, um eine Roadmap für Krypto-Agilität zu entwickeln, die zu Ihrer Architektur passt und die Aufgaben risikobasiert priorisiert. Sehen Sie CBOM Secure in der Praxis, um das kryptografische Inventar aufzubauen, auf dem die Abstraktionsschicht basiert.