Post-Quanten-Kryptografie für Zahlungsdienstleister und PSPs

Ein Zahlungsdienstleister (Payment Service Provider, PSP) kann seine Post-Quanten-Migration jetzt beginnen, und zwar bei den Komponenten, die er allein kontrolliert: TLS auf öffentlichen und partnerseitigen Endpunkten, interner Service-to-Service-Verkehr, SSH-Administration und das kryptografische Inventar, das PCI DSS bereits verlangt. Die Komponenten, die von Dritten abhängen, also Spezifikationen der Kartenorganisationen, EMV-Chip- und Kontaktlos-Kryptografie, Hardware-Sicherheitsmodule (HSMs) und Zahlungsterminals, folgen dem Zeitplan der jeweiligen Anbieter. Beides sauber zu trennen, ist die eigentliche Aufgabe: Migrieren Sie, was Ihnen gehört, dokumentieren Sie, was Ihnen nicht gehört, und führen Sie beides in einem datierten Inventar.

Warum der Schlüsselaustausch zuerst kommt

RSA, ECDSA, EdDSA, ECDH und Diffie-Hellman über endlichen Körpern werden durch den Shor-Algorithmus auf einem ausreichend großen Quantencomputer gebrochen, unabhängig von der Schlüssellänge. Ein belastbares Datum für eine solche Maschine wird hier nicht genannt. Für den Zahlungsverkehr zählt die Form des Risikos, bekannt als Harvest now, decrypt later (HNDL): Heute mitgeschnittener Verkehr ist nur durch den Schlüsselaustausch geschützt, der den Sitzungsschlüssel erzeugt hat. Ein Angreifer, der ihn aufzeichnet, kann ihn daher später entschlüsseln, sobald dieser Schlüsselaustausch brechbar wird. Bei Signaturen ist das anders: Eine Fälschung nützt nur, solange der Signatur noch vertraut wird.

Deshalb kommt der hybride Schlüsselaustausch zuerst, die Signaturen folgen. Für einen PSP ist der aufgezeichnete Verkehr konkret: Autorisierungsnachrichten, Aufrufe von Tokenisierungs-APIs, Settlement- und Abstimmungsdateien, Batch-Übertragungen an Acquirer und Processor sowie administrative Sitzungen in die Cardholder Data Environment. Unser Artikel zu Harvest now, decrypt later erläutert die Argumentation im Detail. Eine hybride Gruppe kombiniert einen klassischen Schlüsselaustausch mit ML-KEM (Module Lattice Key Encapsulation Mechanism), das NIST am 13. August 2024 als FIPS 203 veröffentlicht hat. So bleibt die Sitzung mindestens so stark wie heute, selbst wenn eine der beiden Komponenten versagt.

Was ein PSP jetzt migrieren kann

• Öffentliche HTTPS-Endpunkte: gehostete Zahlungsseiten, Checkout-Skripte, Händler-Dashboards, Webhook-Empfänger und öffentliche APIs. Die hybride Gruppe X25519MLKEM768 (IANA-Codepoint 0x11EC, siehe TLS-Parameter-Registry) wird von aktuellen Versionen von Chrome, Edge und Firefox standardmäßig angeboten; Clients ohne Unterstützung handeln stattdessen die klassische Gruppe aus.
• Service-to-Service-TLS innerhalb der Cardholder Data Environment, wo Sie beide Enden kontrollieren und Bibliotheken nach eigenem Zeitplan aktualisieren können.
• SSH-Administration: OpenSSH 9.9 (19. September 2024) hat mlkem768x25519-sha256 eingeführt, OpenSSH 10.0 (9. April 2025) hat es zur Standard-Schlüsselvereinbarung gemacht, und OpenSSH 10.1 (6. Oktober 2025) warnt, wenn eine Verbindung eine nicht post-quantensichere Schlüsselvereinbarung aushandelt. Siehe die OpenSSH-Release-Notes.
• Vorstandard-Altlasten: Eine noch vorhandene Gruppe X25519Kyber768Draft00 (Codepoint 0x6399) ist veraltet und sollte durch die ML-KEM-Gruppen ersetzt werden.
• Das Inventar selbst, das eher eine Dokumentationsaufgabe als ein Kryptografieprojekt ist und das ein Assessor in der Regel als Erstes anfordert.

Prüfen Sie, was ein Endpunkt heute aushandelt, bevor Sie etwas ändern. Für die ML-KEM-Gruppen ist OpenSSL 3.5 oder neuer erforderlich:

openssl version
openssl s_client -connect api.example.com:443 -groups X25519MLKEM768 </dev/null 2>&1 | grep -i negotiated

Bei nginx, das gegen OpenSSL 3.5 oder neuer gebaut wurde, aktivieren Sie die hybride Gruppe, indem Sie sie vor den klassischen Gruppen aufführen; so bleibt der Fallback erhalten:

ssl_protocols TLSv1.3 TLSv1.2;
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;

Direktivennamen und unterstützte Gruppennamen unterscheiden sich je nach Server und Distribution; prüfen Sie daher Ihren eigenen Build. Testen Sie zuerst in Staging und beobachten Sie nach jeder Produktionsänderung die Handshake-Fehlerraten und die Client-Unterstützung. Der hybride Key Share ist größer als ein klassischer, was auf eingeschränkten Verbindungen und bei alten Middleboxes, die den Handshake inspizieren, eine Rolle spielen kann. Die hybride Schlüsselvereinbarung für TLS 1.3 ist in RFC 10024 (August 2026) spezifiziert.

Was von Kartenorganisationen, HSM-Herstellern und Terminals abhängt

Die folgenden Bereiche liegen nicht in der Entscheidung eines PSP. Post-Quanten-Termine werden dafür hier nicht genannt, da auf dieser Website nur datierte Primärquellen veröffentlicht werden und allein die Kartenorganisationen, EMVCo und die HSM-Hersteller für ihre eigenen Pläne maßgeblich sind.

• EMV-Chip- und Kontaktlos-Kryptografie, einschließlich der Offline-Datenauthentifizierung, die auf per Spezifikation festgelegten RSA- und Elliptische-Kurven-Schlüsseln beruht.
• Netzwerkschnittstellen der Kartenorganisationen und die Schlüsselhierarchien, die sie Acquirern und Processorn vorgeben.
• HSM-Firmware, zertifizierte Konfigurationen und PKCS#11-Unterstützung für ML-KEM und ML-DSA (Module Lattice Digital Signature Algorithm, FIPS 204).
• Key-Block-Formate und PIN-bezogene Kryptografie.
• Hardware von Zahlungsterminals, deren Austauschzyklus in Jahren gemessen wird.

Interpretation, keine Anforderung: Geben Sie jeder dieser Abhängigkeiten eine eigene Zeile im Inventar, mit einem internen Verantwortlichen, der veröffentlichten Position des Anbieters, sofern vorhanden, und einem Prüftermin. Sobald ein Bulletin einer Kartenorganisation oder eine HSM-Release-Note erscheint, ändert sich diese Zeile, und die Historie zeigt, wann Sie davon erfahren haben. Lieferantenfragebögen bei Vertragsverlängerung sind der andere Hebel: Fordern Sie eine schriftliche Roadmap an, statt anzunehmen, dass es eine gibt.

PCI DSS 12.3.3 ist bereits das Rückgrat

PCI DSS v4.0.1, Anforderung 12.3.3, verlangt, dass die eingesetzten Cipher Suites und Protokolle dokumentiert und mindestens einmal alle 12 Monate überprüft werden. Sie besteht aus drei Teilen: einem aktuellen Inventar, das Zweck und Einsatzort jedes Algorithmus angibt, der Überwachung der fortbestehenden Eignung des Eingesetzten und einer dokumentierten Strategie, um auf erwartete Änderungen bei kryptografischen Schwachstellen zu reagieren. Sie ist seit dem 31. März 2025 verpflichtend, davor galt sie als Best Practice; der Standard ist in der Dokumentenbibliothek des PCI SSC erhältlich. Unser Leitfaden zum kryptografischen Inventar nach PCI DSS 12.3.3 behandelt den Aufbau, und die Referenzseite zu PCI DSS v4.0.1 führt die datierten Meilensteine.

Lesen Sie den dritten Teil genau. Erwartete Änderungen bei kryptografischen Schwachstellen: Genau dort gehört Post-Quanten hin. Interpretation: Die Quantenverwundbarkeit des Schlüsselaustauschs mit RSA und elliptischen Kurven ist eine solche erwartete Änderung. Die 12.3.3-Strategie eines PSP kann daher den hybriden Schlüsselaustausch benennen, angeben, welche Endpunkte bereits migriert sind, und die Abhängigkeiten von Kartenorganisationen und HSMs mit ihren Verantwortlichen auflisten. Anforderung 12.3.3 verlangt ML-KEM heute nicht.

DORA: was der Text von EU-Finanzunternehmen verlangt

Die Delegierte Verordnung (EU) 2024/1774 der Kommission, die technischen Regulierungsstandards zum IKT-Risikomanagement unter DORA, gilt für Finanzunternehmen in der EU, einschließlich Zahlungs- und E-Geld-Instituten. Art. 6 verlangt eine Leitlinie zu Verschlüsselung und kryptografischen Kontrollen, die Bestimmungen zur Aktualisierung oder Änderung der kryptografischen Technologie auf Grundlage von Entwicklungen in der Kryptoanalyse enthält. Art. 7 verlangt ein Schlüsselmanagement über den gesamten Lebenszyklus sowie ein Zertifikatsregister für IKT-Assets, die kritische oder wichtige Funktionen unterstützen. Beides ist mit den Meilensteinen auf der DORA-Referenzseite zusammengefasst.

Der Text nennt keinen Algorithmus und setzt kein Post-Quanten-Datum. Interpretation: Art. 6 wird durch eine Leitlinie mit definiertem Auslöser und einem Genehmigungsweg für den Wechsel eines Algorithmus erfüllt, Art. 7 durch ein Zertifikatsregister, das bereits Algorithmus und Schlüssellänge erfasst und damit der naheliegende Ort ist, um zu sehen, was noch auf RSA oder ECDSA beruht. NIS2 Art. 21(2)(h) verlangt über die nationale Umsetzung in ähnlicher Weise Konzepte und Verfahren für den Einsatz von Kryptografie. Dieser Artikel dient der Information und ist keine Rechtsberatung.

Von der Anforderung zum Nachweis

Offizielle Termine für die Planung

Keiner dieser Termine ist spezifisch für den Zahlungsverkehr, und keiner ist eine rechtliche Frist für einen PSP, sofern die letzte Spalte das nicht ausdrücklich sagt. Behalten Sie die Einschränkungen bei, wenn Sie sie intern zitieren.

Beginnen Sie mit den Endpunkten, die Sie sehen können

Der schnellste sinnvolle Schritt besteht darin, zu messen, was Ihre öffentlichen Zahlungsendpunkte heute aushandeln, und danach die Reihenfolge der Arbeiten festzulegen: Scannen Sie Ihre Domain mit PQC Status auf Unterstützung für hybrides ML-KEM, TLS-Versionen und die Zertifikatskette. Führen Sie den Scan für die Checkout-Domain, den API-Host und den Webhook-Host getrennt aus, da sie oft hinter unterschiedlichen Terminierungspunkten liegen. Erfassen Sie jedes Ergebnis mit Datum im 12.3.3-Inventar, tragen Sie die Abhängigkeiten von Kartenorganisationen, HSMs und Terminals als offene Zeilen mit Verantwortlichen ein und setzen Sie die nächste Überprüfung höchstens zwölf Monate später an.