Wenn ich mit den Verantwortlichen für die Systeme einer Organisation über Sicherheit spreche, taucht eine Frage immer wieder auf, ohne dass es eine genaue Antwort darauf gibt: Wie viele Schlüssel, wie viele Zertifikate und welche Algorithmen sind im Einsatz, und wo befinden sie sich? Selten liegt das an fehlender Kompetenz. Häufiger hatte schlicht niemand je den Auftrag oder einen konkreten Anlass, sie zu zählen. Die Systeme sind über die Jahre gewachsen, ein Projekt nach dem anderen, und jedes hat seine eigenen kryptografischen Entscheidungen mitgebracht.
Bevor man also darüber diskutiert, welche Post-Quanten-Algorithmen eingeführt werden sollen, steht eine weniger spektakuläre Aufgabe an: herauszufinden, wo die heutigen eingesetzt werden. Ohne diese Information beruht jeder Migrationsplan auf einem unvollständigen Bild.
Das Problem ist nicht der Quantencomputer
Das Thema wird fast immer als Frage des Zeitpunkts erzählt: Wann wird es einen Quantencomputer geben, der die heute verwendeten Public-Key-Algorithmen wie RSA und die Verfahren auf Basis elliptischer Kurven brechen kann? Niemand weiß das mit Sicherheit, und eine so gestellte Frage führt meist entweder zu Alarmismus oder zum Aufschieben.
Die Leitlinien der italienischen Nationalen Agentur für Cybersicherheit (ACN) nennen ein nützlicheres Kriterium: nicht nach dem Zeitpunkt planen, an dem die Maschine erscheint, sondern danach, wie lange die heutigen Daten geschützt bleiben müssen. Verschlüsselter Datenverkehr kann schon jetzt abgefangen und gespeichert werden, um ihn zu entschlüsseln, sobald dies möglich ist: Diese Strategie ist als Harvest now, decrypt later bekannt. In meiner Arbeit im Gesundheitswesen wiegt dieses Kriterium schwerer als anderswo: Ein Befund, der heute in wenigen Millisekunden übertragen wird, muss unter Umständen jahrzehntelang vertraulich bleiben.
Das Risiko betrifft vor allem die Public-Key-Kryptografie, die für den Schlüsselaustausch und für Signaturen eingesetzt wird. Symmetrische Algorithmen wie AES bleiben bei ausreichender Schlüssellänge sicher.
Der Bezugsrahmen ist inzwischen klar abgesteckt. Im August 2024 hat das NIST die ersten drei Post-Quanten-Standards veröffentlicht: FIPS 203 (ML-KEM) für die Schlüsseletablierung sowie FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA) für digitale Signaturen. Ende Oktober 2026 folgte die endgültige Fassung von IR 8547, die den Übergang weg von den angreifbaren Public-Key-Algorithmen beschreibt. Die wichtigsten Etappen sind 2030 und 2035, mit unterschiedlichen Fristen je nach Einsatzzweck und Sicherheitsniveau. In Europa sieht die 2025 veröffentlichte koordinierte Roadmap vor, die nationalen Pläne bis Ende 2026 anzustoßen, Anwendungsfälle mit hohem Risiko und kritische Infrastrukturen bis 2030 zu migrieren und den Übergang für möglichst viele Systeme bis 2035 abzuschließen.
Für Systeme, die über Jahre im Betrieb bleiben, ist das ein knapper Zeitrahmen. Und planen lässt sich nur, was man erfasst hat.
Versteckte Kryptografie in Software und Prozessen
Wenn eine Organisation beginnt, ihre kryptografischen Abhängigkeiten zu erfassen, fängt sie meist bei den TLS-Zertifikaten an. Das liegt nahe: Sie sind der sichtbarste Punkt, und für ihre Erfassung gibt es ausgereifte Werkzeuge. Sind die Daten aus der Infrastruktur jedoch gesammelt, zeigt sich, dass ein erheblicher Teil der Abhängigkeiten gar nicht dort liegt. Er steckt im Anwendungscode, in den Bibliotheken einer Unternehmenssoftware, in den Konnektoren zu externen Systemen und in den Geräten, die mit der zentralen Software kommunizieren.
Und manchmal steckt er in den Prozessen rund um die Technologie. Es kommt vor, dass Schlüssel und Zugangsdaten, die an der Quelle gut geschützt sind, einige manuelle Zwischenschritte durchlaufen, bevor sie die Anwendung erreichen, die sie nutzt: ein Versand per E-Mail, ein freigegebener Ordner, eine Kopie auf einem Zwischenserver. Solche Lösungen sind entstanden, um einen echten Bedarf zu decken, oft unter Zeitdruck, und werden mit der Zeit Teil des Arbeitsalltags. Niemand betrachtet sie als Kryptografie, und doch sind genau sie die Stellen, die man einzeln wiederfinden und überprüfen muss, wenn sich Algorithmen, Schlüssel oder Formate ändern.
An diesem Punkt verändert sich die Frage.
Neben dem Wissen, welche Algorithmen im Einsatz sind, muss man verstehen, wer sie ändern kann, welche Komponenten davon abhängen und was nach einem Austausch nicht mehr funktionieren würde.
Es handelt sich um eine Form technischer Schulden, die selten in einem Backlog auftaucht: kryptografische Schulden. Die Bibliotheken funktionieren weiter, die Zertifikate werden erneuert, die Verbindungen bleiben bestehen. Was oft niemand prüfen konnte, ist, wie aufwendig es wäre, die kryptografischen Funktionen auszutauschen, auf denen all das beruht.
Auch bei den Begriffen braucht es etwas Ordnung. Ein Zertifikat enthält einen öffentlichen Schlüssel, RSA oder auf Basis elliptischer Kurven, sowie die Signatur der ausstellenden Stelle, die einen anderen Algorithmus verwenden kann. Eine TLS-Verbindung nutzt wiederum getrennte Mechanismen für den Schlüsselaustausch, der die Vertraulichkeit schützt und als Erstes von Harvest now, decrypt later betroffen ist, und für die Authentifizierung, die die Authentizität schützt und schon heute Schlüssel und Geräte betrifft, die lange im Einsatz bleiben sollen. Ein Inventar, das diese Ebenen vermischt, hilft bei der Planung einer Migration nicht weiter.
Was eine unbekannte Abhängigkeit kostet
Wenn die Dringlichkeit real wird, muss, wer kein Inventar hat, drei Dinge gleichzeitig tun: herausfinden, wo die Abhängigkeiten liegen, verstehen, welche davon kritisch sind, und migrieren. Und das unter dem Zeitdruck dessen, der bereits im Verzug ist.
Die Folgen einer Migration im Notfallmodus sind zuallererst technischer Natur. Prioritäten werden nach Gefühl statt nach Risiko gesetzt. Legacy-Komponenten, die die neuen Algorithmen nicht unterstützen, tauchen erst auf, wenn die Arbeit bereits läuft. Manche Bibliotheken lassen sich nicht aktualisieren, ohne die Schnittstellen zu ändern, die sie bereitstellen. Als selbstverständlich angenommene Kompatibilitäten erweisen sich als nie erprobt. Und Systeme aus unterschiedlichen Zeiten müssen weiter miteinander kommunizieren, während sich die Algorithmen ändern.
Hinzu kommt ein Aspekt, der gern unterschätzt wird: Post-Quanten-Schlüssel und -Signaturen sind deutlich größer als die heutigen. Eine ECDSA-Signatur belegt einige Dutzend Byte, eine ML-DSA-Signatur einige Kilobyte. Felder mit fester Länge, Protokolle mit engen Grenzen und Geräte mit wenig Speicher verkraften den Wechsel möglicherweise nicht, und das sollte man vorher wissen.
Dann ist da noch die organisatorische Seite: Ohne Inventar wird es auch schwierig, Compliance nachzuweisen. Man kann einen vernünftigen Plan haben und trotzdem keine Nachweise vorlegen können.
Software so gestalten, dass sie sich ändern kann
Der erste Schritt besteht meiner Ansicht nach darin, ein Kryptografie-Inventar aufzubauen. Gebraucht wird weniger eine Liste von Algorithmen als eine Landkarte, die für jede kryptografische Funktion angibt:
- wozu sie dient: Verschlüsselung, Schlüsselaustausch, Signatur, Authentifizierung;
- welchen Algorithmus sie mit welchen Parametern verwendet;
- welche Zertifikate und Schlüssel sie betrifft;
- in welchen Bibliotheken und Komponenten sie implementiert ist, und in welcher Version;
- welche Systeme und Dienste von ihr abhängen;
- wer technisch für sie verantwortlich ist und welcher Anbieter sie gegebenenfalls betreut;
- wie ihr Lebenszyklus aussieht und wie austauschbar sie tatsächlich ist.
Es muss nicht vom ersten Tag an perfekt sein. Es muss existieren, aktuell bleiben und es ermöglichen, die Systeme nach Kritikalität und nach der Lebensdauer der Daten zu priorisieren. Für die Beschreibung gibt es auch Standardformate wie die Cryptography Bill of Materials (CBOM) von CycloneDX, die nützlich sind, wenn Informationen zwischen mehreren Anbietern ausgetauscht werden müssen.
Wie man in der Praxis vorgeht, hängt vom Kontext ab. In vielen Projekten arbeiten wir direkt am Code und greifen in die kryptografischen Bibliotheken ein: Wir integrieren sie, aktualisieren sie und ersetzen sie, wenn nötig. In Ökosystemen wie dem Gesundheitswesen arbeiten dagegen oft viele Anbieter mit ihren jeweiligen Produkten am selben Informationssystem. Dort ist unser Beitrag vor allem architektonischer Natur: Statt an einer einzelnen Bibliothek anzusetzen, helfen wir der Organisation, Grenzen festzulegen, Dienste und Integrationen abzubilden und eine Architektur aufzubauen, in der die Abhängigkeiten klar und steuerbar sind.
Im Gesundheitswesen, und allgemeiner in der öffentlichen Verwaltung, liegt die größte Schwierigkeit oft nicht in der Technologie. Viele Beteiligte, mehrjährige Projekte und der natürliche personelle Wechsel führen dazu, dass sich das Wissen auf unterschiedliche Dokumente, Systeme und Kompetenzen verteilt. So entwickeln sich lange und komplexe Projekte nun einmal. Dazu kommen branchenspezifische Rahmenbedingungen: Geräte, die viele Jahre im Einsatz bleiben, Schnittstellen zu anderen Einrichtungen, die sich nicht von heute auf morgen ändern lassen, signierte Dokumente, die dauerhaft überprüfbar bleiben müssen. Deshalb ist ein gemeinsames Inventar mehr wert als das Gedächtnis jedes Einzelnen.
Nicht alle Abhängigkeiten sind gleich dringlich. Die Signatur eines Dokuments, das über Jahrzehnte gültig bleiben muss, stellt ein anderes Problem dar als die Authentifizierung eines internen Dienstes, die jedes Jahr erneuert wird. Genau dafür ist das Inventar da: zu entscheiden, wo man anfängt, welche Abhängigkeiten zuerst anzugehen sind und welche Systeme eine Neukonzeption erfordern.
Der zweite Schritt betrifft die Art, wie Software entworfen wird. Ob sich ein Algorithmus austauschen lässt, hängt von der Architektur ab: Sind die kryptografischen Entscheidungen über Bibliotheken, Konfigurationen und Anwendungscode verstreut, erfordert eine Änderung Eingriffe in viele Komponenten und eine erneute Prüfung ihres Zusammenspiels.
Krypto-Agilität entsteht, bevor man sie braucht.
Das bedeutet, kryptografische Funktionen hinter klar definierten Schnittstellen zu kapseln, fest im Code verankerte Algorithmen zu vermeiden, die Verwaltung von Schlüsseln und Zertifikaten zu automatisieren und dabei manuelle Zwischenschritte zu beseitigen sowie bei neuen Entwicklungen vorzusehen, dass während des Übergangs mehrere Algorithmen nebeneinander bestehen können. Es ist auch der einfachste Weg, um zu verhindern, dass eine neue Anwendung schon mit schwer austauschbaren Abhängigkeiten an den Start geht.
In manchen Fällen erfolgt dieses Nebeneinander über hybride Verfahren, die einen klassischen und einen Post-Quanten-Mechanismus kombinieren, sodass der Schutz hält, solange mindestens einer der beiden sicher bleibt. Das ist kein fernes Szenario: Mehrere Browser verwenden bereits standardmäßig einen hybriden Schlüsselaustausch, der eine elliptische Kurve mit ML-KEM kombiniert. Zwei Algorithmen nebeneinanderzustellen reicht allerdings nicht aus: Es braucht standardisierte und geprüfte Kombinationen, ein angemessenes Schlüsselmanagement und Kompatibilität zwischen allen beteiligten Systemen. Die europäische Roadmap empfiehlt diesen Ansatz, wo er angemessen ist.
Wenn Sie morgen früh in einem Ihrer kritischen Systeme einen kryptografischen Algorithmus austauschen müssten, aufgrund einer neuen Vorschrift oder einer plötzlich entdeckten Schwachstelle: Wüssten Sie, wo Sie anfangen sollen?
