Sebastien Rousseau
Kontakt ›

Post-Quanten-Zahlungsinfrastruktur: Warum Banken bestehende Rails ersetzen statt nachrüsten

ML-KEM und ML-DSA passen nicht sauber in die Rails, die SWIFT MT und ISO 20022 transportieren. Die ehrliche technische Antwort: Nachrüstung ist ein kontrollierter Migrationsplan mit kurzer Haltbarkeit, Ersatz ist das einzige stabile Ziel.

10 Min. Lesezeit

Post-Quanten-Zahlungsinfrastruktur: Warum Banken bestehende Rails ersetzen statt nachrüsten

Die kryptografischen Primitive, die heute jede Wholesale-Zahlung im Produktivbetrieb authentifizieren — RSA, ECDSA, ECDH — haben ein Ablaufdatum. Der US-amerikanische Quantum Computing Cybersecurity Preparedness Act ⧉ schrieb dieses Ablaufdatum Ende 2022 ins Bundesbeschaffungsrecht. Das BIS Working Paper No. 1208 ⧉ überführte denselben Ablauf in den aufsichtsrechtlichen Rahmen der Zentralbanken. NIST FIPS 203 ⧉ und FIPS 204 ⧉ veröffentlichten im August 2024 den Ersatz.

Die Zahlungsinfrastruktur hat noch nicht verarbeitet, was das bedeutet.

Dieser Artikel ist das technische Plädoyer für Ersatz statt Nachrüstung. Er ist für Architekten geschrieben, die die Algorithmen bereits verstehen und entscheiden müssen, was mit SWIFT MT, ISO-20022-pacs- und -pain-Nachrichten, RTGS-Schnittstellen, HSM-Beständen und den darunter liegenden Zertifikatshierarchien geschehen soll.

Executive Summary / Wichtigste Erkenntnisse

  • Ernten-jetzt-Entschlüsseln-später (HNDL) ist die operative Bedrohung. Angreifer zeichnen 2026 verschlüsselten Zahlungsverkehr auf, um ihn zu entschlüsseln, sobald ein kryptanalytisch relevanter Quantencomputer (CRQC) existiert. Der erfasste Verkehr umfasst Settlementanweisungen, Begünstigtendaten und Authentifizierungsmaterial mit langlebiger Sensibilität.
  • NIST hat den Ersatz standardisiert. ML-KEM (FIPS 203) für Schlüsselkapselung und ML-DSA (FIPS 204) für digitale Signaturen sind die Standardwahl. SLH-DSA (FIPS 205) deckt den zustandslosen Hash-basierten Rückfall ab.
  • Die Größendifferenz bricht bestehende Annahmen. Öffentliche Schlüssel und Signaturen sind 5–20× größer als die RSA-2048-Äquivalente. Das kollidiert mit MTU in Zahlungsnetzen, mit Annahmen zu festen Puffern in MT-Nachrichtenhandlern und mit dem kryptografischen Durchsatz installierter HSM-Flotten.
  • Hybrid (klassisch + PQC) ist das Migrationsvehikel, nicht das Ziel. Hybrid-TLS und Hybrid-X.509 kaufen zwei bis drei Jahre Interoperabilität, während die Produktions-Rails ersetzt werden. Sie lösen das zugrundeliegende Kapazitätsproblem nicht.
  • PKI ist die tragende Wand. Eine Zertifizierungsstelle, deren Signaturalgorithmus fälschbar wird, entwertet jedes Zertifikat darunter. Die institutionelle Exposition der Bank ist die Vertrauenskette, nicht ein einzelner Endpunkt.
  • Krypto-Agilität ist die architektonische Eigenschaft, auf die hin zu konstruieren ist. Algorithmen-Identifikatoren, Schlüsselformate, Signaturhüllen und HSM-Partitionen müssen sämtlich parametrisierbar sein. Alles, was zur Übersetzungszeit auf RSA festgenagelt ist, ist technische Schuld, die gleichzeitig fällig wird.

Ernten jetzt, Entschlüsseln später: Das Bedrohungsmodell, das die Option zu warten ausschließt #

HNDL kehrt die übliche kryptografische Zeitachse um. Konventionelle Risikobewertung fragt, wann sich die Bedrohung materialisiert. HNDL fragt, wann die heute erfassten Daten für einen Angreifer nutzbar werden. Für Zahlungsnachrichten — Identitäten von Begünstigten, Kontonummern, strukturierte Verwendungszweckdaten, Sanktionsprüfungs-Nutzlasten, bankinterne Settlementanweisungen — beträgt das Sensibilitätsfenster Jahre bis Jahrzehnte. Der größte Teil dieses Verkehrs wird gerade jetzt irgendwo aufgezeichnet.

Der Zeitplan der NSA für CNSA 2.0 ⧉ gibt Systemen der nationalen Sicherheit bis 2035, um den Übergang abzuschließen. Finanzaufseher bewegen sich auf schnelleren Zeitplänen — die Erwartungen der PRA an operative Resilienz ⧉ behandeln kryptografische Agilität als Drittparteien-Konzentrationsrisiko. Die Erwartung 2026 lautet, dass materielle Zahlungsrails ihren PQC-Migrationsplan in ihrer Resilienz-Selbstattestierung veröffentlichen.

Der HNDL-Angreifer braucht heute keinen CRQC. Er braucht:

  1. Netzwerkposition. Anzapfungen von Seekabeln, Mitschnitte auf ISP-Ebene und kompromittierte Middleboxes sind alle relevant. Wholesale-Zahlungsverkehr konzentriert sich auf eine kleine Anzahl von Netzpfaden.
  2. Speicher. Ein Petabyte strukturierter Zahlungsdaten ist 2026 ein handhabbares Archiv.
  3. Geduld. Die Erfassung kostet pro abgefangener Nachricht nichts. Der Ertrag kommt später.

Das Migrationsargument lautet daher nicht „Quantencomputer könnten 2035 eintreffen". Es lautet: „Jede TLS-Sitzung, die heute Abend mit RSA-2048-Schlüsselaustausch abgeschlossen wird, ist so lange exponiert, wie die darin enthaltenen Daten sensibel bleiben."

Das Größenproblem ist das Engineering-Problem #

Die öffentliche Diskussion zur PQC-Migration fokussiert sich tendenziell auf die Algorithmenwahl. Das härtere Problem ist dimensional.

Primitive Öffentlicher Schlüssel Signatur / Chiffretext
RSA-2048 256 Byte 256 Byte (Signatur)
ECDSA P-256 64 Byte 64 Byte (Signatur)
ML-KEM-768 1.184 Byte 1.088 Byte (Chiffretext)
ML-DSA-65 1.952 Byte 3.309 Byte (Signatur)
SLH-DSA-128f 32 Byte 17.088 Byte (Signatur)

Diese Zahlen bilden sich direkt auf Versagensmodi ab, für die bestehende Zahlungsinfrastruktur nie konstruiert wurde:

Der Nachrüstungspfad besteht darin, diese Einschränkungen einzeln zu triagieren — größere Puffer hier, schnellere HSMs dort, Fragmentierungstoleranz in den Middleboxes. Das ist eine vertretbare Sechs-Monats-Brücke. Es ist keine Architektur.

Nachrüsten oder Ersetzen: Die Entscheidung, die das Programm definiert #

Die ehrliche Einrahmung lautet: Nachrüstung ist ein kontrollierter Migrationsplan mit kurzer Haltbarkeit, und Ersatz ist das einzige stabile Ziel. Die Entscheidung ist, was die Bank zuerst finanziert und wie lange das Nachrüstungsfenster offen bleibt, bevor es zum dauerhaften Pfusch wird.

Nachrüstung bedeutet:

Diese Arbeit ist machbar. Sie behebt das zugrundeliegende Problem nicht, nämlich dass SWIFT MT und viele ISO-20022-Implementierungen die kryptografische Hülle in einem Nachrichtenformat kodieren, das den Algorithmus festnagelt. Der nächste Algorithmenwechsel — und es wird einen geben, wenn ML-KEM irgendwann Schwäche zeigt oder ein neuer Standard ihn ablöst — führt dieselbe Migration erneut auf denselben Rails durch.

Ersatz bedeutet, anzuerkennen, dass die kryptografische Schicht keine Eigenschaft des Nachrichtenformats ist. Sie ist Eigenschaft eines separierbaren Hüllendienstes, den das Nachrichtenformat aufruft. Konkret:

Das Ersatzdesign überlebt den nächsten Algorithmenwechsel, ohne dass die Rail erneut angefasst wird.

Die krypto-agile Architektur, Schicht für Schicht #

Die für die PQC-Migration relevanten Infrastrukturschichten sind nicht die geschäftlichen Schichten von „Daten, Steuerung, Wirtschaft", die zu einem generischen Banknarrativ passen. Die relevanten Schichten sind kryptografisch.

Schicht Was sie tut Die PQC-Frage Architektonische Vorgabe
HSM / Schlüsselverwaltung Erzeugt, speichert und operiert auf Schlüsselmaterial unter Hardware-Isolation Unterstützt die installierte HSM-Firmware ML-KEM, ML-DSA und eine hybride Schlüsselkapselungs-API? Wie groß ist die Durchsatzdifferenz beim Signieren gegenüber ECDSA auf derselben Hardware? Jede HSM-Partition nach Algorithmusunterstützung und Sekundenkapazität inventarisieren. Alles ausmustern, was ohne Firmware-Pfad auf RSA festgenagelt ist. Dedizierte PQC-Partitionen vor dem Produktiv-Cutover aufstellen.
PKI / Zertifizierungsstelle Stellt aus, widerruft und verkettet Vertrauen über X.509-Zertifikate Kann die CA heute mit ML-DSA signieren? Gibt es einen getesteten Prozess für die Rotation der Root und die Neuausstellung der Kette? Sind CRL- und OCSP-Responder auf das ML-DSA-Signaturgewicht dimensioniert? Den CA-Stack als tragende Wand behandeln. Jetzt eine PQC-fähige Sub-CA etablieren. Die Root-Rotation an der längstlebigen Zertifikatsabhängigkeit ausrichten, nicht am Bequemen.
Transport / Netzwerk Terminiert TLS, IPsec und MACsec zwischen Zahlungs-Endpunkten Tolerieren Load Balancer, WAF und Middlebox-Pfad hybride Handshakes, die die bestehende MTU überschreiten? Sind Session-Resumption-Tickets auf PQC-Schlüssel dimensioniert? TLS-Terminierung an eine krypto-agile Grenze verlagern (Sidecar oder Mesh). MTU-Richtlinie auf Zahlungs-VPNs erhöhen. Den gesamten Pfad mit bewusst induzierter Fragmentierung testen.
Anwendung / Nachrichten-Payload Transportiert SWIFT MT-, ISO-20022-pacs- / pain- / camt-Nachrichten und ihre kryptografischen Hüllen Toleriert der Nachrichtenhandler der Rail ML-DSA-große signierte Hüllen? Sind zwischengeschaltete Parser algorithmus-bewusst, oder kürzen sie bei der Länge? Hülle vom Payload trennen. An einer Service-Grenze signieren, nicht im Nachrichtenformat-Handler. Algorithmen-Identifikatoren als Daten behandeln, nicht als Schema.
Audit / Beweis Erzeugt die kryptografische Beweiskette, auf die sich Aufseher und Kunden verlassen Sind historische signierte Datensätze noch verifizierbar, sobald der Signaturalgorithmus außer Kraft gesetzt ist? Gibt es einen langfristigen Archivsignaturplan? Archive mit einem Hash-basierten Primitiv (SLH-DSA) gegensignieren, um Zusicherung zu erhalten, die jeden einzelnen Algorithmenbruch überlebt. Die Audit-Kette als regulatorisches Artefakt behandeln, nicht als Nebenprodukt des Builds.

Die Disziplin besteht darin, jede Algorithmenwahl auf jeder Schicht zu einem Konfigurationswert zu machen. Die Institution, die RSA-2048 auf einer dieser Schichten fest codiert, erbt ein koordiniertes End-of-Life-Ereignis, sobald dieser Algorithmus fällt.

Was das je nach Bank-Typ bedeutet #

Das Expositionsprofil unterscheidet sich nach Institut. Die Vorgaben unterscheiden sich entsprechend.

Globale Banken #

Globale Banken betreiben die größten installierten HSM-Flotten, die längsten Zertifikatsketten und die komplexesten Netzpfade zwischen Gegenparteien. Das dominierende Risiko ist nicht die Algorithmenwahl — es sind die Koordinationskosten, Algorithmen über hunderte interner Dienste und dutzende externer Gegenparteien gleichzeitig zu wechseln.

Die Vorgabe lautet, die PQC-fähige CA, die krypto-agile Transportgrenze und den algorithmus-parametrisierten Signaturdienst als 2026-Arbeit zu finanzieren, bevor eine einzige Rail nachgerüstet wird. Die Nachrüstung wird dann zu einer routinemäßigen Produktivänderung innerhalb eines bekannten Rahmens. Ohne diesen Rahmen verhandelt jede Rail-Nachrüstung dieselben Architekturentscheidungen erneut.

Regionale Banken #

Regionale Banken haben weniger algorithmische Angriffsfläche, aber proportional weniger Spezialisten. Das dominierende Risiko ist die HSM-Anbieter-Bindung an Algorithmen, zu deren Unterstützung sich der Anbieter nicht verpflichtet hat.

Die Vorgabe lautet, PQC-Unterstützung — konkret ML-KEM und ML-DSA mit getestetem Firmware-Upgrade-Pfad — ab 2026 in jede HSM-Vertragsverlängerung zu schreiben. Banken ohne diese Klausel erben einen erzwungenen Hardware-Ersatz nach dem Zeitplan des Anbieters, nicht nach ihrem eigenen.

Fintechs und PSPs #

Zahlungsdienstleister und Fintechs sitzen typischerweise zwischen einer Bank-Gegenpartei und einem Händler- oder Endnutzersystem. Ihre kryptografische Exposition liegt auf beiden Seiten an der API-Grenze.

Die Vorgabe lautet, in kommerziellen Gesprächen 2026 eine Hybrid-TLS-Schnittstelle — klassisch plus ML-KEM — auf der bankzugewandten Seite als Mindestanforderung zu veröffentlichen. Das Fintech, das mit bereits demonstrierter PQC-Interoperabilität antritt, gewinnt Integrationszyklen gegen das Fintech, das noch nicht begonnen hat.

Corporate Treasurer #

Treasurer betreiben kryptografische Infrastruktur nicht direkt. Sie konsumieren sie — jede Bank-API, jede sichere Dateiübertragung, jede signierte Bestätigung hängt von der PKI der Bank ab.

Die Vorgabe lautet, jeder Bank-RFP 2026 drei Fragen hinzuzufügen: welche PQC-Algorithmen setzt die Bank heute im kundenseitigen TLS ein, was ist der Plan der Bank für ML-DSA-signierte Zahlungsbestätigungen, und wie beabsichtigt die Bank, die Verifizierbarkeit historischer signierter Datensätze zu erhalten, sobald RSA ausgemustert wird. Banken, die diese Fragen nicht beantworten können, signalisieren etwas über ihre zugrundeliegende technische Reife.

Was als Nächstes passiert #

Die erste Welle der PQC-Bereitstellung im Zahlungsverkehr wird für Endnutzer unsichtbar sein. Hybrid-TLS taucht im Handshake auf, Zertifikatsketten wachsen, die HSM-Signaturlatenz steigt um wenige Millisekunden, und die Rails laufen weiter. Das ist der Erfolgspfad.

Die sichtbaren Versagen werden nachrüstungsgetrieben sein: eine Rail, die eine ML-DSA-signierte Hülle ohne Kürzung nicht annehmen kann, eine CA, deren CRL-Verteilungspunkt unter dem neuen Signaturgewicht erstickt, eine Middlebox, die hybride Handshakes in neu sortierte ClientHellos zerlegt. Diese Versagen werden bis 2027 in der Produktion landen.

Die architektonische Entscheidung 2026 ist, ob die Ersatzinfrastruktur finanziert wird, die die Nachrüstung irrelevant macht, oder eine Folge rail-spezifischer Korrekturen, die jeweils einzeln billiger aussehen und sich zu einer längeren, teureren Migration aufsummieren. Die Bank, die den ersten Pfad wählt, wird durch den Übergang ruhigere Operationen führen. Die Bank, die den zweiten wählt, wird den Rest des Jahrzehnts damit verbringen, Aufsehern Incident Reviews zu erklären.

PQC ist kein Kryptografie-Problem im Gewand eines Infrastruktur-Problems. Es ist ein Infrastruktur-Problem, das die Kryptografie zufällig angestoßen hat.

Häufig gestellte Fragen #

Gibt es eine Frist, die diese Arbeit erzwingt?

Die harten regulatorischen Fristen sind jurisdiktional. Der US-amerikanische Quantum Computing Cybersecurity Preparedness Act ⧉ bindet Bundessysteme. Der NSA-CNSA-2.0-Zeitplan ⧉ zielt für nationale Sicherheitssysteme auf 2035. Die Veröffentlichung BIS Project Leap ⧉ und das Arbeitsprogramm des FSB ziehen diesen Horizont für systemische Zahlungsinfrastruktur nach vorn. HNDL bedeutet, dass die operative Uhr lange vor jedem dieser nominellen Daten zu laufen begonnen hat.

Warum ist ML-KEM die empfohlene Schlüsselkapselung und nicht etwas Schnelleres?

ML-KEM (die standardisierte Version von CRYSTALS-Kyber) hatte unter den Gitter-Kandidaten die stärkste Kombination aus kleinen Chiffretext- und Schlüsselgrößen, mit reifen Implementierungen und Seitenkanal-Härtung. NIST veröffentlichte es als FIPS 203 ⧉. Schnellere Kandidaten existieren, tragen aber größere Volumina oder schwächere Vertrauensintervalle bei den Sicherheitsparametern.

Warum nicht SLH-DSA überall statt ML-DSA verwenden?

SLH-DSA (die standardisierte Version von SPHINCS+) ist Hash-basiert und stützt sich daher ausschließlich auf Hashfunktions-Sicherheit, die konservativste verfügbare Annahme. Seine Signaturen sind 5–20× größer als die von ML-DSA. Das ist für Archiv-Gegensignierung akzeptabel, aber für transaktionales Signieren, bei dem die Größe pro Nachricht zählt, untragbar. Das Standardmuster lautet: ML-DSA für Produktivsignaturen und SLH-DSA für Archiv-Zusicherung.

Kann eine Bank einfach warten, bis die Rails PQC-Profile veröffentlichen?

Eine Bank, die wartet, erbt das Migrationsfenster, das die Rail veröffentlicht — und das ist kürzer als der interne Änderungszyklus der Bank selbst. Bis SWIFT, der lokale RTGS-Betreiber und die relevanten CCPs jeweils ihr PQC-Profil veröffentlichen, wird das Migrationsfenster zwölf bis vierundzwanzig Monate betragen. Banken, die ihre CA-, Transport- und HSM-Fähigkeit nicht vorgebaut haben, werden es ohne operative Abkürzungen nicht einhalten.

Was ist die einzelne hebelstärkste Investition zuerst?

Eine PQC-fähige Sub-Zertifizierungsstelle, integriert in die bestehende PKI, die dual-algorithmische Zertifikate (RSA plus ML-DSA) ausstellen kann, ohne das Produktiv-Vertrauen zu stören. Damit ist die Rotations-Primitive etabliert. Alles andere — Transport-Upgrades, HSM-Partitionsplanung, Nachrichtenhüllen-Änderungen — kann sich darum gruppieren.

Quellen #

Zuletzt geprüft .

Zuletzt überprüft .