Krypto-Agilität: Verteidigungssysteme für den Algorithmentausch konzipieren

Die meisten Verteidigungssysteme versagen nicht, weil ihre Kryptografie bei der Inbetriebnahme schwach war. Sie versagen, weil die Kryptografie gleich blieb, während die Welt sich weiterentwickelte. Ein Algorithmus, der bei der Inbetriebnahme solide war, wird veraltet, dann abgeraten, dann verboten – und das System, das ihn fest einkodiert hat, benötigt nun ein mehrjähriges Multi-Lieferanten-Engineering-Programm, um ein einziges Primitiv zu ändern. Krypto-Agilität ist die Disziplin, Systeme so zu bauen, dass der Tausch eines Algorithmus eine Konfigurations- und Deployment-Aufgabe ist, kein Redesign. Da die Migration zur Post-Quantum-Kryptografie nun eine feste Anforderung für langlebige Verteidigungsdaten ist, ist Agilität keine Verfeinerung mehr – sie ist die Voraussetzung dafür, den nächsten Übergang zu überstehen, ohne das System neu aufzustellen.

Was Krypto-Agilität wirklich bedeutet

Krypto-Agilität ist die Eigenschaft eines Systems, die es ermöglicht, Algorithmen, Schlüsselgrößen und Protokolle zu wechseln, ohne die davon abhängige Anwendung neu zu architekturieren. Der Test ist einfach: Wie lange und wie viele Codezeilen dauert es, einen Algorithmus durch einen anderen zu ersetzen? In einem nicht-agilen System lautet die Antwort „wir öffnen das Design erneut", weil der Algorithmusname, die Schlüssellänge und der Parametersatz über Anwendungslogik, Serialisierungsformate, Zertifikatsvorlagen und Protokoll-Handler verstreut sind. In einem agilen System lautet die Antwort „wir ändern eine Richtlinie", weil all diese Entscheidungen von dem Moment an, in dem das System gebaut wurde, in die Konfiguration ausgelagert wurden.

Agilität ist nicht dasselbe wie eine gute Krypto-Bibliothek zu haben. Ein Programm kann die am besten geprüfte verfügbare Bibliothek verlinken und dennoch völlig unflexibel sein, weil die Anwendung eine bestimmte Funktion aufruft – RSA_sign, eine benannte Kurve, einen festen Digest – direkt aus dem Geschäftscode. Dass die Bibliothek austauschbar ist, hilft nicht, wenn die Aufrufstellen es nicht sind. Agilität ist eine architektonische Eigenschaft des Gesamtsystems, kein Feature einer einzelnen Abhängigkeit.

Warum Verteidigungssysteme es jetzt brauchen

Zwei Zeitpläne kollidieren im Verteidigungsbeschaffungswesen. Der erste ist die Nutzungsdauer der Plattform. Ein Kampffahrzeug, eine Funkfamilie oder eine C2-Suite wird voraussichtlich zwanzig bis vierzig Jahre betrieben. In dieser Zeitspanne werden kryptografische Standards mehrfach wechseln – der Übergang von SHA-1, die Abkündigung von 1024-Bit-RSA und der Wechsel zur authentifizierten Verschlüsselung erfolgten alle innerhalb einer einzigen Plattformgeneration. Jeder heute in ein System eingebaute Algorithmus wird längst veraltet sein, bevor die Hardware ausgemustert wird.

Der zweite Zeitplan ist die Quantenbedrohung. Ein kryptografisch relevanter Quantencomputer würde RSA und Elliptische-Kurven-Kryptografie vollständig brechen, und die „Jetzt ernten, später entschlüsseln"-Strategie bedeutet, dass Angreifer den heutigen verschlüsselten Datenverkehr erfassen und speichern können, bis diese Maschine existiert. Verteidigungsdaten mit jahrzehntelangen Vertraulichkeitsanforderungen sind daher bereits gefährdet, auch wenn der Quantencomputer noch nicht existiert. Die Reaktion der Standards – CNSA 2.0 und die NIST-Post-Quantum-Suite – setzt feste Migrationsfristen. Ein System ohne Agilität kann diese Fristen nicht einhalten, ohne einen Re-Engineering-Aufwand, den der Zeitplan nicht erlaubt. Für das Bedrohungsmodell und den Zeitplan dahinter, siehe unsere Analyse der Quantencomputer-Bedrohung für Verteidigungskommunikation.

Mit einem kryptografischen Inventar beginnen

Man kann nicht migrieren, was man nicht sehen kann, und man kann nicht agil machen, was man nicht lokalisiert hat. Das erste Ergebnis eines Krypto-Agilitätsprogramms ist ein kryptografisches Inventar – zunehmend formalisiert als kryptografische Stückliste, oder CBOM. Es ist ein vollständiger Katalog aller Stellen, an denen das System Kryptografie verwendet: jeder Algorithmus und Modus, jede Schlüssellänge, jedes Zertifikat und sein Aussteller, die auf jeder Schnittstelle ausgehandelten Protokollversionen, die Bibliotheken, die die Primitive implementieren, und – entscheidend – die Daten, die jede Instanz schützt, und wie lange diese Daten vertraulich bleiben müssen.

Das Inventar ist fast immer überraschender als das Programm erwartet. Kryptografie versteckt sich in Firmware, für die niemand den Quellcode hat, in Drittanbieter-Binärdateien, deren Algorithmenauswahl undokumentiert ist, in Hardware-Sicherheitsmodulen mit festen Fähigkeiten und in Protokoll-Standardwerten, die zur Laufzeit ausgehandelt werden, statt zur Entwurfszeit ausgewählt zu werden. Ein nützliches Inventar erfasst Erkennungssicherheit und Eigentümerschaft für jeden Eintrag und unterscheidet zwischen „wir haben das im Quellcode gelesen", „wir haben das auf dem Netzwerk beobachtet" und „der Hersteller hat uns das mitgeteilt". Es muss ein lebendes Artefakt sein, das von der Build-Pipeline neu generiert wird, keine einmalige Prüfung, die am Tag nach ihrer Fertigstellung veraltet ist.

Vom Inventar zur Risikopriorisierung

Das Inventar ist nicht nur eine Karte – es ist der Input zur Priorisierung. Zwei Attribute bestimmen die Migrationsreihenfolge: die Vertraulichkeitslebensdauer der geschützten Daten und die Exposition des Kanals. Daten, die dreißig Jahre lang geheim bleiben müssen und eine externe Verbindung kreuzen, sind das Erste, was migriert werden muss, weil sie genau das sind, was „Jetzt ernten, später entschlüsseln" anvisiert. Kurzlebige Daten auf einem internen, physisch geschützten Segment können warten. Ohne das Inventar ist diese Triage unmöglich, und das Programm migriert entweder alles auf einmal (was nicht finanzierbar ist) oder migriert zuerst die einfachen Dinge (was die Hochrisiko-Daten am längsten exponiert lässt).

Die Algorithmus-Abstraktionsschicht

Der strukturelle Kern eines agilen Systems ist eine Algorithmus-Abstraktionsschicht – ein kryptografischer Anbieter oder ein Dienst-Interface, das zwischen Anwendungscode und den konkreten Implementierungen sitzt. Anwendungscode benennt niemals einen Algorithmus. Stattdessen drückt er eine Absicht aus: „diese Nachricht signieren", „einen Sitzungsschlüssel mit diesem Peer aufbauen", „diesen Datensatz im Ruhezustand verschlüsseln". Neben der Absicht verweist er auf eine benannte Richtlinie – zum Beispiel signing.c2-link.v3 – und die Abstraktionsschicht löst diese Richtlinie zur Laufzeit in einen konkreten Algorithmus, eine Schlüssellänge und einen Parametersatz auf.

Der Vorteil besteht darin, dass ein Algorithmentausch zur Richtlinienbearbeitung wird. Das Ändern von signing.c2-link.v3 von einer Elliptische-Kurven-Signatur zu einer Post-Quantum-Signatur ist eine Konfigurationsänderung, die pro Umgebung ausgerollt wird, ohne Änderung des aufrufenden Codes und ohne Neukompilierung der Anwendung, die die Signaturanforderung stellt. Dieselbe Indirektion ermöglicht es einem Programm, verschiedene Algorithmen in verschiedenen Einsatzgebieten oder für verschiedene Geheimhaltungsstufen aus einem einzigen Binary zu betreiben und eine Migration zu staffeln – alte Richtlinie in Produktion, neue Richtlinie im Test – ohne den Codebase aufzuspalten.

Die korrekte Gestaltung des Interface ist wichtig. Es sollte grob genug sein, dass Anwendungsentwickler nicht versehentlich daran vorbeikommen können (kein „gib mir einen rohen AES-Schlüssel"-Notausgang, der die Wahl wieder fest verdrahtet), und es sollte Algorithmus-Metadaten offenlegen, damit Aufrufer erfassen können, welche Richtlinie angewendet wurde. Das HSM, der Schlüsseltresor und die Rotationsmechanik befinden sich ebenfalls hinter dieser Schicht; für die betriebliche Seite davon, siehe unseren Leitfaden zum Secrets Management in Verteidigungs-CI/CD-Pipelines.

Protokolle, Zertifikate und gespeicherte Daten versionieren

Agilität an der Aufrufstelle ist notwendig, aber nicht ausreichend. Kryptografische Artefakte überleben den Moment ihrer Erstellung – ein heute verschlüsselter Datensatz kann in fünfzehn Jahren entschlüsselt werden, ein jetzt ausgestelltes Zertifikat wird von Peers für seine gesamte Gültigkeitsdauer überprüft, und eine Protokollsitzung wird zwischen zwei Systemen auf unterschiedlichen Update-Zeitplänen ausgehandelt. Jedes davon muss genug Metadaten tragen, um eine Algorithmusänderung zu überstehen.

Protokolle. On-the-Wire-Formate müssen explizite Algorithmusidentifikatoren und Versionsfelder enthalten, damit zwei Peers einen gemeinsamen Algorithmus aushandeln können, anstatt einen anzunehmen. Ein Protokoll, das fest kodiert „die Signatur ist ECDSA-P384", kann nicht aktualisiert werden, ohne jeden eingesetzten Peer gleichzeitig zu brechen – ein Flag Day, der über eine Feldtruppe hinweg operativ unmöglich ist. Ein Protokoll, das aushandelt „ich unterstütze diese Algorithmussuites, du unterstützt jene, wir einigen uns auf die stärkste gemeinsame" aktualisiert sich reibungslos, während Endpunkte in ihrem eigenen Tempo migrieren.

Zertifikate. Zertifikatsprofile müssen neue Signatur- und Schlüsselkapselungs-Algorithmusidentifikatoren aufnehmen können, und der Validierungspfad darf einen unbekannten, aber richtlinienkonformen Algorithmus nicht ablehnen. Die Public-Key-Infrastruktur selbst braucht eine agile Wurzel: Wenn die Zertifizierungsstelle nur einen Algorithmus ausstellen kann, wird die PKI unabhängig davon, wie agil die Endpunkte sind, zum Flaschenhals.

Gespeicherte Daten. Jeder verschlüsselte Datensatz oder signierte Gegenstand muss erfassen, welcher Algorithmus und welcher Schlüssel ihn geschützt haben. Ohne dieses Tag kann ein zukünftiges System nach einer Algorithmusänderung weder Legacy-Daten entschlüsseln noch verifizieren – die Daten werden unlesbar, nicht weil der Schlüssel verloren ging, sondern weil das System vergessen hat, welches Schema es verwendet hat. Diese Metadaten machen eine Migration reversibel und ermöglichen die Koexistenz von altem und neuem Chiffretext während des Übergangs.

Ein phasenweiser Migrationsplan

Mit dem Inventar, der Abstraktionsschicht und versionierten Artefakten wird die Migration selbst zu einer kontrollierten, reversiblen Abfolge statt zu einem Flag Day. Ein praxistauglicher Plan läuft in fünf Phasen ab.

Phase 1 – Inventar. Das CBOM aufbauen und automatisieren und Einträge nach Vertraulichkeitslebensdauer und Exposition triage. Diese Phase produziert den Migrations-Backlog und legt die Abhängigkeiten offen, die sonst zu Feldausfällen führen würden.

Phase 2 – Abstraktion. Die Algorithmus-Abstraktionsschicht einführen und jeden bestehenden kryptografischen Aufruf darüber leiten. Keine Anwendungslogik sollte einen Algorithmus direkt aufrufen. Am Ende dieser Phase ist das System nicht sicherer als zuvor, aber es ist nun änderbar – die Voraussetzung für alles, was folgt.

Phase 3 – Hybride Modi. Die Schicht so konfigurieren, dass sie einen klassischen und einen Post-Quantum-Algorithmus gemeinsam ausführt – zum Beispiel einen hybriden Schlüsselaustausch, der einen Elliptische-Kurven-Austausch mit einem gitterbasierten Schlüsselkapselungsmechanismus kombiniert. Die kombinierte Konstruktion bleibt sicher, wenn eine Komponente später bricht, was sowohl gegen einen Quantenbruch des klassischen Algorithmus als auch gegen eine unvorhergesehene Schwäche im neueren Post-Quantum-Algorithmus absichert. Hybride Modi pro Umgebung hinter Richtlinien ausrollen und Interoperabilität mit Alliierten- und STANAG-gesteuerten Systemen validieren, bevor Standards geändert werden.

Phase 4 – Priorisierte Migration. Anhand der Risikoreihenfolge des Inventars zuerst Daten mit langer Vertraulichkeit und extern exponierte Daten migrieren, dann zu kurzlebigen internen Daten übergehen. Die Abdeckung bei jedem Schritt gegen das CBOM messen, damit das Programm genau berichten kann, welcher Anteil der Hochrisiko-Daten durch Post-Quantum-Kryptografie geschützt ist. Die detaillierte Compliance-Sequenzierung für diese Phase ist im CNSA 2.0-Migrations-Fahrplan dargelegt.

Phase 5 – Außerbetriebnahme. Einen klassischen Algorithmus erst entfernen, wenn jeder abhängige Peer und jeder gespeicherte Datenpfad unter der neuen Richtlinie neu verschlüsselt oder neu verschlüsselt worden ist – was das Inventar und die gespeicherten Daten-Tags verifizierbar statt annehmbar machen. Die Außerbetriebnahme ist der letzte Schritt genau deshalb, weil sie der einzige irreversible ist; alles davor kann rückgängig gemacht werden, wenn Interoperabilität oder Leistung zurückgeht.

Häufige Fehlermuster

Drei Fehler wiederholen sich programmatisch. Der erste ist, Agilität als Bibliothekstausch zu behandeln – eine Post-Quantum-fähige Bibliothek zu verlinken, während direkte Algorithmenaufrufe im Anwendungscode verbleiben, was ein System produziert, das genauso wenig agil ist wie zuvor. Der zweite ist, vor der Inventarisierung zu migrieren, was garantiert übersehene Abhängigkeiten, die als Feldausfälle auftauchen, wenn ein nicht-katalogisierter Peer oder eine Firmware-Komponente den neuen Algorithmus nicht aushandeln kann. Der dritte ist, den alten Algorithmus zu früh zu löschen, bevor jeder gespeicherte Datensatz und jeder Peer migriert hat, was Legacy-Daten unverifierbar oder unlesbar macht. Jeder davon wird durch dieselbe Disziplin vermieden: zuerst inventarisieren, abstrahieren bevor migriert wird, und zuletzt außer Betrieb nehmen.

Was das für die Beschaffung bedeutet

Krypto-Agilität ist am günstigsten, wenn sie bei der Vertragsvergabe eine Anforderung ist, und am teuersten, wenn sie nachträglich in ein eingesetztes System eingebaut wird. Programme, die neue Verteidigungssoftware spezifizieren, sollten eine Algorithmus-Abstraktionsschicht, eine gepflegte kryptografische Stückliste und versionierte kryptografische Artefakte als Abnahmekriterien fordern – nicht als künftige Erweiterung. Die heute konzipierten Systeme werden den Post-Quantum-Übergang und mindestens einen Übergang danach erleben. Sie so zu bauen, dass Algorithmen kostengünstig getauscht werden können, ist der Unterschied zwischen einer Konfigurationsänderung und einem Neuaufstellungsprogramm.