Quantensicherheit: Krypto-Agilität im Core Banking

Harald Summa befasst sich mit Quantensicherheit — Harald A. Summa, Gründer und langjähriger Geschäftsführer des eco Verbands der Internetwirtschaft, Chairman der Initiative Diplomatic Quantum Leap (DCQL) DCQL

Die fortschreitende Bedrohung durch „Harvest now, decrypt later“-Angriffe trifft Banken an ihrer verwundbarsten Stelle: den nachgelagerten Datenbanken, Mainframes und Data Platforms der Core-Banking-Architektur. Da sensible Finanz- und Kundendaten oft Schutzfristen von mehreren Jahrzehnten aufweisen, mutieren klassische, asymmetrische Verschlüsselungsverfahren (wie RSA oder ECC) innerhalb der zentralen IT-Infrastruktur schon heute zum akuten Sicherheitsrisiko. Der zwingende Übergang zur Quantensicherheit und damit zu einer quantensicheren Post-Quanten-Kryptografie (PQC) und der Aufbau von Krypto-Agilität lassen sich daher nicht als isolierte Krypto-Projekte betrachten – sie müssen als fundamentale Architekturreform tief in den Kernsystemen und deren API-Gateways verankert werden, um die langfristige Datenintegrität und DORA-Konformität des Instituts zu garantieren.

von Harald A. Summa, Chairman der Initiative Diplomatic Quantum Leap (DCQL) & Dr. Florian Fröwis, Quantum Security Director, DCQL

Dr. Florian Fröwis befasst sich mit Quantensicherheit — Dr. Florian Fröwis, Quantum Security Director, DCQL DCQL

Die Europäische Zentralbank (EZB) und US-Behörden wie das Finanzministerium warnen Banken ausdrücklich vor den Risiken durch Quantenangriffe auf bestehende Verschlüsselungsverfahren. Daher müssen Banken und Finanzdienstleister jetzt dringend mit der Einführung von Quantensicherheitsverfahren beginnen. Die häufig geäußerte Empfehlung zur Inventarisierung der verwendeten Verschlüsselungsverfahren ist zwar richtig, greift aber zu kurz.

Keineswegs sollten die Institute warten, bis ihre Kryptografie vollständig inventarisiert ist, sondern Bestandsaufnahme und Umsetzung müssen parallel laufen. Das bedeutet: Bekannte, besonders gefährdete Datenflüsse zuerst absichern und zugleich das Krypto-Inventar vervollständigen. Das gilt auch für Data Platforms, die Mainframes, Analysewerkzeuge und Schnittstellen verbinden.

Daten mit langer Schutzfrist zuerst

Das parallele Vorgehen ist notwendig, weil die Gefahr von „Harvest now, decrypt later“ groß ist, also das Risiko, dass Angreifer heute verschlüsselte Kommunikation speichern und später mit leistungsfähigen Quantencomputern entschlüsseln. Wann solche Rechner verfügbar sein werden, ist zwar offen. Jedoch können langfristig vertrauliche Kunden-, Kredit- und Transaktionsdaten dennoch bereits heute betroffen sein: Ihre Schutzfrist reicht womöglich über die verbleibende Sicherheit des Schlüsselaustauschs hinaus.

Ein späterer Algorithmuswechsel schützt bereits abgegriffene Daten nicht rückwirkend.“

RSA und elliptische Kurvenverfahren (ECC) stecken etwa in TLS-Zertifikaten, VPNs, Signaturen und Schlüsselaustauschprotokollen. Auf Mainframes führen Kryptodienste Operationen aus; Hardware-Sicherheitsmodule (HSM) schützen private Schlüssel. Auch API-Gateways, Nachrichtenvermittlung und Dateiübertragungen gehören ins Inventar. Nutzdaten werden häufig mit AES verschlüsselt. Ein starkes AES-Verfahren allein genügt jedoch nicht, wenn sein Schlüssel über ein künftig angreifbares Verfahren vereinbart wird.

Das Inventar muss deshalb Algorithmus, Zweck, Schlüsselablage, Schutzfrist, Verantwortliche und Herstellerabhängigkeiten mit dem jeweiligen Datenfluss verknüpfen. Diese Inventarisierung ist eine Voraussetzung für Krypto-Agilität, also die Möglichkeit, Verfahren und Schlüssel kontrolliert wechseln zu können. Dafür müssen auch HSM-Firmware, Zertifikatsketten und Gegenstellen mitspielen. Eine praktikable betriebliche Kennzahl ist die gemessene Dauer, die ein getesteter Wechsel der kryptografischen Verfahren tatsächlich benötigt.

PQC und QKD unterscheiden

Autor: Harald Summa, DCQL

Harald A. Summa, der Gründer und langjährige Geschäftsführer des eco Verbands der Internetwirtschaft, fungiert heute als Chairman der Initiative Diplomatic Quantum Leap (DCQL, Webseite). In dieser Rolle treibt er die internationale Zusammenarbeit bei der Migration auf quantensichere Technologien voran. Dabei bringt er seine jahrzehntelange Erfahrung aus der digitalen Infrastruktur in die Absicherung kritischer Finanzarchitekturen ein.

Post-Quanten-Kryptografie (PQC) läuft auf klassischen Rechnern. NIST hat unter anderem ML-KEM zur Schlüsseleinigung sowie ML-DSA und SLH-DSA für Signaturen standardisiert. Hybride Verfahren kombinieren klassische und Post-Quanten-Komponenten. Bei geeigneter Konstruktion bleibt die Schlüsseleinigung geschützt, solange eine Komponente sicher bleibt. Das setzt korrekte Verknüpfung, Authentisierung und Schutz vor dem Rückfall auf schwächere Verfahren voraus. Da Post-Quanten-Schlüssel und -Signaturen deutlich größer sind, sind Last- und Interoperabilitätstests nötig.

Quantenbasierte Schlüsselverteilung (QKD) erzeugt gemeinsames Schlüsselmaterial über optische Verbindungen und benötigt spezielle Hardware. Sie ersetzt weder Datenverschlüsselung noch Authentisierung oder Signaturen. Reichweite, vertrauenswürdige Zwischenknoten und Verfügbarkeit begrenzen den Einsatz. Das BSI und europäische Partnerbehörden priorisieren hybride PQC-Lösungen. Die NSA empfiehlt QKD für US-Nationalsicherheitssysteme wegen technischer Grenzen derzeit nicht. Für Banken ist QKD daher eine gesondert zu begründende Ergänzung.

Schlüssel als Dienstleistung unter DORA

Autor: Dr. Florian Fröwis, DCQL

Dr. Florian Fröwis lächelt im dunklen Sakko und weißen Hemd vor unscharfem Hintergrund; als Director Quantum Security leitet er die Migration kritischer IT zur Quantensicherheit.

Dr. Florian Fröwis fungiert als Director Quantum Security bei der Initiative Diplomatic Quantum Leap (DCQL) (Webseite), wo er die strategische Migration kritischer IT-Infrastrukturen auf quantensichere Verfahren leitet. Parallel dazu bringt der promovierte Quantenphysiker seine Expertise als Fachexperte für Quantum-Safe Solutions bei dem Unternehmen ID Quantique/IonQ ein.

Externe Schlüsselverteilung ist als IKT-Dienstleistung in das DORA-Drittparteienrisikomanagement einzubeziehen. Die Verantwortung bleibt beim Institut. Unterstützt der Dienst kritische oder wichtige Funktionen, sind insbesondere Prüfungsrechte, Unterauftragnehmer, Ausfallszenarien und eine getestete Exit-Strategie relevant.

Technisch bedeutet das: Kann ein Ersatzdienst die Schnittstellen bedienen? Bleiben Daten nach dem Wechsel entschlüsselbar? Wie werden Schlüssel sicher übertragen oder neu erzeugt und Altbestände nachweisbar gelöscht?

Zwei Anbieter schaffen keine Unabhängigkeit, wenn sie dieselbe Cloud, Netzstrecke oder Schlüsselplattform nutzen. Solche Abhängigkeiten sind als Konzentrationsrisiko zu bewerten. „Souverän“ muss überprüfbare Kontrolle über Schlüssel, Administration, Updates und Wiederanlauf bedeuten; ein europäischer Standort allein reicht nicht. DORA schreibt weder QKD noch einen bestimmten PQC-Algorithmus vor. Harald Summa, Florian Fröwis, DCQL/dk