Neue Algorithmen, alte Infrastruktur: Warum die Post-Quanten-Migration Jahre dauert

Teil 1 endete mit der Feststellung, dass die Bedrohung in der Zukunft liegt, die Migration aber jetzt beginnt – und mit dem Versprechen zu erklären, warum diese Migration so schwierig ist.

Auf den ersten Blick wirkt die Post-Quanten-Migration wie ein Algorithmus-Upgrade: Man ersetzt die anfällige Kryptografie, aktualisiert die Bibliotheken, erneuert die Zertifikate und macht weiter. Doch Kryptografie ist selten eine isolierte Komponente, denn sie steckt in Systemen, Prozessen, Produkten und Vertrauensbeziehungen.

Nehmen wir ein Kundenportal: Die öffentlich erreichbare Verbindung zu aktualisieren ist eine Änderung. Die Zertifikate, Geräte, Anwendungen, Lieferanten und Partnerintegrationen zu aktualisieren, die das Portal am Laufen halten, ist ein weit größeres Vorhaben. Über die Wahl neuer Algorithmen hinaus müssen Organisationen herausfinden, wo Public-Key-Kryptografie eingesetzt wird, welche Systeme davon abhängen, und Änderungen koordinieren, ohne die Dienste zu stören, auf die sich Menschen täglich verlassen.

Public-Key-Kryptografie hat so gut funktioniert, dass sie in unserer Infrastruktur unsichtbar geworden ist. Genau dieser Erfolg ist jetzt das Migrationsproblem.

Wie Public-Key-Kryptografie überall gelandet ist

1976 veröffentlichten Whitfield Diffie und Martin Hellman die Arbeit, mit der die Public-Key-Kryptografie eingeführt wurde. Jahrelang blieb sie weitgehend eine Forschungstechnologie. Das Internet gab ihr dann einen enormen praktischen Zweck: Parteien, die sich nie begegnet waren, konnten geschützt kommunizieren und Identitäten überprüfen. Mit dem Wachstum des Onlinehandels wurde Kryptografie Teil der Infrastruktur, die ihn erst möglich machte.

Bart Preneel schätzt, dass heute zig Milliarden Bibliotheken und Anwendungen auf Milliarden von Geräten auf Public-Key-Kryptografie angewiesen sind – als Hinweis auf die Größenordnung, nicht als exakte Zählung [1].

Dieser Fußabdruck entstand durch unzählige gewöhnliche Entscheidungen: Organisationen kauften Anwendungen, verbanden Dienste, installierten Geräte und führten Cloud-Plattformen ein, und mit all dem kam Kryptografie, oft als stillschweigende Abhängigkeit. Mit der Zeit wurde sie in Systeme eingebettet, deren Verantwortliche selten über die zugrunde liegenden Algorithmen nachdenken mussten.

Wo sie tatsächlich steckt

Wir verlassen uns auf Kryptografie für weit mehr als sicheres Surfen im Web. Sie schützt VPN- und SSH-Verbindungen, prüft die Software-Updates, die unsere Geräte installieren, sichert Kartenzahlungen ab und erlaubt es Cloud-Diensten und anderen Systemen, ihre Identität über Zertifikate nachzuweisen.

Preneels Beispiel der Waschmaschine macht das greifbar. Heute ist es schwer, eine ohne App zu kaufen, und wer die App abschaltet, verliert Funktionen – also landet die Maschine im Internet [2]. Hinter diesem Komfort stehen der Cloud-Dienst des Herstellers, Geräteidentitäten und Software-Updates, und jedes davon kann kryptografische Abhängigkeiten mit sich bringen. Überträgt man dieses Muster auf Industriesensoren, Fahrzeuge, Medizingeräte und intelligente Zähler, wird der Umfang der Migration deutlicher.

Ein Serveradministrator kann eine Bibliothek vielleicht noch diese Woche aktualisieren. Ein Gerät, das bereits beim Kunden zu Hause oder in einer Fabrik installiert ist, hat dagegen womöglich einen viel engeren Update-Pfad. Die PQC-Migration ist daher ebenso ein Produkt-, Lieferanten- und Embedded-Systems-Problem wie ein Rechenzentrumsproblem.

Niemand überblickt das Ganze

Fragt man eine Organisation, wo sie RSA, Diffie-Hellman oder elliptische Kurvenkryptografie einsetzt, hängt die Antwort meist davon ab, wen man fragt.

Sicherheitsteams kennen vielleicht die öffentlich erreichbaren Zertifikate, während Infrastrukturteams VPNs und interne Zertifikatsdienste betreiben. Anwendungsteams erben Kryptografie über Bibliotheken, Cloud-Teams konfigurieren verwaltete Dienste, und Produktentwickler sind auf Firmware anderer Unternehmen angewiesen. Der Einkauf wiederum verhandelt die Verträge, die darüber entscheiden, ob Updates überhaupt geliefert werden – und jede dieser Gruppen sieht nur einen Teil des Bildes.

Eine Anwendung kann auf einer Bibliothek beruhen, die ein Protokoll mit Zertifikaten aus einer Public-Key-Infrastruktur umsetzt. Private Schlüssel liegen womöglich in einem Hardware-Sicherheitsmodul (HSM), dessen Fähigkeiten von Firmware, Schnittstellen und Zertifizierung abhängen.

„Wir implementieren Kryptografie nicht selbst“ mag stimmen – die Anwendung hängt trotzdem davon ab. „Darum kümmert sich der Lieferant“ mag ebenfalls stimmen – die Organisation muss trotzdem wissen, was der Lieferant leisten kann. Ein Algorithmuswechsel kann so zu einem Betriebssystem-Upgrade, einem Gerätetausch oder einer Vertragsverhandlung werden, und kein einzelnes Team kann all das allein bewältigen.

Lektion 1: TLS

Die Geschichte sicherer Webverbindungen zeigt anschaulich, wie lange kryptografische Übergänge dauern können.

TLS 1.1 wurde 2006 standardisiert, TLS 1.2 im Jahr 2008. Mit der Veröffentlichung standen die Protokolle Implementierern zur Verfügung, aktualisieren konnte sie jedoch nicht jeden Browser, jeden Server, jedes Betriebssystem und jedes Netzwerkgerät, das sie hätte nutzen müssen [3, 4].

Ein altes Protokoll abzuschalten ist eine eigene Herausforderung. Der im Oktober 2014 veröffentlichte POODLE-Angriff legte eine schwere Schwachstelle in SSL 3.0 offen. Daraufhin kündigte Mozilla an, das Protokoll in Firefox standardmäßig zu deaktivieren, und die IETF erklärte es im Juni 2015 offiziell für veraltet [5, 6]. Das sind unterschiedliche Meilensteine: eine Schwachstelle erkennen, Produkte ändern und ein Protokoll formal zurückziehen – und keiner davon sagt etwas darüber aus, wann jedes abhängige System es tatsächlich nicht mehr nutzte. Nach Preneels Auswertung von SSL-Labs-Daten zu den 150.000 meistbesuchten Websites dauerte es rund ein Jahrzehnt, bis die meisten von ihnen SSL 3.0 aufgegeben hatten – und das sind die schnellen Umsteiger, nicht der lange Rest [2].

Ein Dienstverantwortlicher kann wissen, dass ein altes Protokoll verschwinden sollte, und muss dennoch erst herausfinden, welche Kunden, Geräte oder Integrationen beim Abschalten den Zugang verlieren würden. Einen Ersatz zu unterstützen und die alte Option zu entfernen sind getrennte Aufgaben, und die zweite verlangt Einblick in Systeme außerhalb der unmittelbaren Kontrolle des Betreibers.

Standardisiert heißt nicht eingesetzt.

Lektion 2: Telekommunikationsstandards

Die Herausforderung kann beginnen, bevor eine Sicherheitsverbesserung überhaupt einen Standard erreicht. Sicherheitsspezifikationen für Mobilfunknetze entstehen bei 3GPP, ETSI und GSMA, und die Aktualisierung kryptografischer Profile kann Jahre dauern, weil Geräte aus verschiedenen Releases weiterhin zusammenarbeiten müssen [7].

2020 stieß mein Team bei einem Netzausrüster eine Diskussion über die Einführung von 256-Bit-Algorithmen für Mobilfunknetze an. Wir suchten Unterstützung bei anderen großen Unternehmen, unter anderem mit Schreiben an weitere Standardisierungsgremien und Arbeitsgruppen. In jenem Jahr hatten wir keinen Erfolg, vor allem wegen der Implementierungskosten. Später kam das Thema zurück: In Release 18 spezifizierte ETSI SAGE 256-Bit-Algorithmen für die Funkschnittstelle, und die Spezifikation MILENAGE-256 erschien als Teil von Release 19 [8, 9].

Eine Sicherheitsverbesserung kann technisch fundiert sein und trotzdem Jahre darauf warten, dass sich das Ökosystem einigt, dass sie die Kosten wert ist.

Lektion 3: EMV und der lange Rest

Zahlungssysteme machen das Koordinationsproblem greifbar – selbst in einer Branche mit starken Anreizen und etablierten Standards.

Laut Preneel beschloss die Zahlungsbranche 2008, die Kryptografie von EMV-Karten von RSA auf elliptische Kurven umzustellen, mit einem Plan, der rund 20 Jahre dauern sollte. Nach einigen Jahren wurde der Plan aufgegeben und inzwischen neu gestartet [2]. Öffentlich belegt ist ein wichtiger Meilenstein: Im Oktober 2021 veröffentlichte EMVCo die ECC-Unterstützung für seine Spezifikation kontaktbehafteter Chips, sodass RSA und ECC parallel bestehen können [10]. ECC ist nicht quantenresistent, doch das Beispiel zeigt, wie schwierig schon ein Übergang zwischen etablierten Algorithmen sein kann.

Preneel verweist auf die Größenordnung: sechs bis sieben Milliarden Karten, aber mehr als 100 Millionen Terminals [2]. Karten lassen sich in regelmäßigen Zyklen neu ausgeben, Terminals folgen dagegen anderen Zeitplänen und betreffen andere Organisationen. Eine neue Karte kann den Übergang nicht abschließen, wenn die Orte, an denen sie eingesetzt wird, sie nicht unterstützen.

Zusammen zeigen TLS, die Standardisierung in der Telekommunikation und EMV, warum kryptografische Übergänge so lange dauern können: Die Schwierigkeiten beginnen womöglich schon bei der Standardisierung, setzen sich in der Produktentwicklung fort und halten im Einsatz an, während Organisationen versuchen, mit älteren Systemen kompatibel zu bleiben. Große Plattformen können sich in Umgebungen, die sie selbst kontrollieren, schnell bewegen. Ältere Clients, kleinere Lieferanten und eingebettete Geräte folgen dagegen eigenen Zeitplänen, und diese verbleibenden Abhängigkeiten können bestimmen, wie lange Altunterstützung bestehen bleibt.

Standardisierung ist ein Meilenstein, keine Ziellinie

Mit der Veröffentlichung von ML-KEM, ML-DSA und SLH-DSA im August 2024 hat das NIST finalisierte Standards für Schlüsselaustausch und digitale Signaturen bereitgestellt [11]. Das war ein großer Schritt in Richtung Einsatz, aktualisierte aber nicht automatisch Bibliotheken, HSM-Firmware, Zertifikatsdienste, VPNs oder Lieferantenverträge.

Für Kunden ist „Wir unterstützen PQC“ der Beginn eines Gesprächs, denn dahinter kann eine experimentelle Implementierung stehen, eine Early-Access-Funktion oder eine Produktivfähigkeit, die nur in bestimmten Konfigurationen verfügbar ist. Die nützlichen Fragen sind konkreter:

• Welche Produktversion unterstützt es, und ist sie allgemein verfügbar?
• Deckt die Unterstützung Schlüsselaustausch, Signaturen oder beides ab?
• Funktioniert sie mit unserem HSM und den angebundenen Systemen?
• Welche Validierung oder Zertifizierung gilt?
• Können wir das alte Verfahren sicher abschalten?

Eine Funktion kann im Portfolio eines Lieferanten existieren und trotzdem in der Produktversion oder HSM-Konfiguration fehlen, die Ihre Organisation tatsächlich betreibt.

Die verborgenen Stellen

Manche Abhängigkeiten werden erst sichtbar, wenn etwas vertrauenswürdig sein muss: Ein Zertifikat authentisiert einen Dienst, Firmware prüft die nächste Stufe des Bootvorgangs eines Geräts, und digitale Signaturen helfen Geräten und Anwendungen zu entscheiden, ob Software als authentisch akzeptiert werden soll.

Für die Vertraulichkeit erzeugt Harvest-Now, Decrypt-Later Dringlichkeit, weil abgefangene Daten über Jahre ihren Wert behalten können. Signaturen werfen eine andere Frage auf: Wie stellt ein System Authentizität fest, wenn sein bestehender Prüfmechanismus nicht mehr vertrauenswürdig ist? Eine alte Signatur wird nicht automatisch ungültig, wenn sich kryptografische Fähigkeiten ändern; die Sorge ist, ob künftige Angreifer Material fälschen könnten, das ein noch laufendes System akzeptieren würde.

Bei langlebigen Geräten muss womöglich gerade der Mechanismus, der ein sicheres Upgrade ausliefern soll, selbst erst aktualisiert werden. Preneel zählt Secure Boot und Update-Signaturen zu den schwierigsten Migrationsbereichen [2]. Signatursysteme brauchen daher oft eine eigene Migrationsplanung, getrennt von Verschlüsselungssystemen.

Wo man anfängt

Zurück zum Kundenportal: Seine Verbindungen sind nur die sichtbaren Eingänge zu einer größeren Sammlung von Zertifikaten, Bibliotheken, Geräten, Partnern und Lieferanten. Public-Key-Kryptografie wurde schwer sichtbar, weil diese Komponenten ihren Einsatz so bequem machten – und die Migration verlangt nun, zu verstehen, was sich angesammelt hat, bevor man es sicher ändern kann.

Ein sinnvoller erster Schritt ist, einen wichtigen Geschäftsdienst auszuwählen, seine kryptografischen Abhängigkeiten nachzuverfolgen und die Komponente zu finden, die am schwersten zu ersetzen wäre. Denn diese Komponente sagt womöglich mehr über den Zeitplan der Migration aus als die Wahl des Algorithmus.

Teil 3 zeigt, wie sich diese Transparenz aufbauen lässt: herausfinden, wo Kryptografie steckt, und sie mit den Diensten verbinden, die von ihr abhängen.

Quellen und weiterführende Literatur

1. Preneel, B. (2026, 1. Juni). Post-quantum cryptography (PQC): The risk of being late [Konferenzfolien]. SecAppDev 2026. https://handouts.secappdev.org/handouts/2026/bartpreneel_post-quantum-cryptography-pqc-the-risk-of-being-late.pdf
2. Preneel, B. (2026, 12. Oktober). The quantum threat: Why act now? [Video]. YouTube. https://www.youtube.com/watch?v=Gg8hODiE4FA
3. Dierks, T., & Rescorla, E. (2006). The Transport Layer Security (TLS) protocol version 1.1 (RFC 4346). RFC Editor. https://doi.org/10.17487/RFC4346
4. Dierks, T., & Rescorla, E. (2008). The Transport Layer Security (TLS) protocol version 1.2 (RFC 5246). RFC Editor. https://doi.org/10.17487/RFC5246
5. Mozilla Security. (2014, 14. Oktober). The POODLE attack and the end of SSL 3.0. Mozilla Security Blog. https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/
6. Barnes, R., Thomson, M., Pironti, A., & Langley, A. (2015). Deprecating Secure Sockets Layer version 3.0 (RFC 7568). RFC Editor. https://doi.org/10.17487/RFC7568
7. Preuß Mattsson, J., Comak, P., & Karakoç, F. (2021, 29. Juni). The evolution of cryptography in mobile networks and how to secure them in the future [Blogbeitrag]. Ericsson. https://www.ericsson.com/en/blog/2021/6/evolution-of-cryptographic-algorithms
8. Jost, C. (2024, 18. April). 3GPP Rel-18 security – the overview [Blogbeitrag]. Ericsson. https://www.ericsson.com/en/blog/2024/4/3gpp-release-18-security-overview
9. 3rd Generation Partnership Project. (2026, Januar). Specification of the MILENAGE-256 algorithm set. Document 1: General (3GPP TS 35.234, Version 19.0.0; ETSI TS 135 234). ETSI. https://etsi.org/deliver/etsi_ts/135200_135299/135234/19.00.00_60/ts_135234v190000p.pdf
10. EMVCo. (2021, 28. Oktober). EMV® chip specifications to support elliptic curve cryptography [FAQ]. https://www.emvco.com/news-publications/emv-chip-specifications-to-support-elliptic-curve-cryptography/
11. National Institute of Standards and Technology. (2024, 13. August). NIST releases first 3 finalized post-quantum encryption standards [Pressemitteilung]. https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards