Oracle und Post-Quanten-Kryptografie: Strategien fürs Heute

Die Ära der Quantencomputer rückt näher – und damit auch das Ende klassischer Verschlüsselungsverfahren. Oracle reagiert mit einer umfassenden Post-Quanten-Strategie, die hybride Kryptografie-Ansätze und FIPS-standardisierte Algorithmen kombiniert. Besonders das „Harvest now and decrypt later“-Szenario zwingt Unternehmen zum sofortigen Handeln.

Quantencomputer bedrohen etablierte Kryptografie-Standards

Quantencomputer versprechen exponentielle Rechenleistung gegenüber klassischen Systemen – mit gravierenden Folgen für die IT-Sicherheit. Etablierte kryptografische Verfahren wie RSA, ECDH und ECDSA verlieren ihre Schutzwirkung, sobald Quantensysteme praxistauglich werden. Die Industrie ist sich einig: Herkömmliche Verschlüsselung wird obsolet, auch wenn der genaue Zeitpunkt umstritten bleibt.

Die Herausforderung besteht darin, Kryptografie-Infrastrukturen zu schaffen, die auf konventioneller Hardware laufen und gleichzeitig gegen beide Angriffsvektoren – klassisch und quantenbasiert – resistent sind.

Komplexe Anforderungen an PQC-Migration

Die Einführung quantenresistenter Kryptografie konfrontiert Unternehmen mit mehrschichtigen Herausforderungen:

Regulatorische Compliance: Neue Federal Information Processing Standards (FIPS) definieren zugelassene PQC-Algorithmen. Organisationen müssen zertifizierte Verfahren implementieren.

Systeminteroperabilität: Aktualisierte Verschlüsselungsmechanismen müssen nahtlos mit bestehenden Infrastrukturen zusammenarbeiten. Standardisierung ist essentiell.

Praktikabilität für Anwender: PQC-Lösungen müssen einfach implementierbar sein, ohne Stabilitäts- oder Performance-Einbußen zu verursachen.

API-Kompatibilität: Neue Schnittstellen müssen sowohl klassische als auch quantenresistente Anforderungen erfüllen und Legacy-Systeme unterstützen.

Symmetrische Verschlüsselung: Schlüsselgrößen verdoppeln reicht nicht

Bei Daten im Ruhezustand reduzieren Quantenangriffe die Sicherheit symmetrischer Verfahren. Eine Verdopplung der Schlüssellängen erscheint zunächst als einfache Lösung – funktioniert jedoch nur bei absoluter Schlüsselvertraulichkeit.

Das Problem: Datenverschlüsselungsschlüssel werden typischerweise von Hauptschlüsseln umhüllt, die in Key-Management-Diensten mit Hardware-Sicherheitsmodulen verwaltet werden. Remote-Zugriffe erfordern gesicherte Kommunikationskanäle. Der Schutz ruhender Daten hängt somit unmittelbar vom Schutz der Übertragungswege ab. Konsequenz: Schlüsselaustausch muss über quantensichere Protokolle wie TLS 1.3 mit PQC-Cipher-Suites erfolgen.

Aktive versus passive Quantenangriffe auf Netzwerke

Bei der Absicherung von Netzwerkkommunikation unterscheiden Sicherheitsexperten zwei Bedrohungsszenarien:

Aktive Angriffe: Echtzeit-Man-in-the-Middle-Szenarien mit Quantencomputern sind noch nicht realisierbar. Die bestehende PKI mit ECDSA- und RSA-Zertifikaten bleibt vorerst akzeptabel – wenn auch Anpassungen bei der Schlüsselgenerierung erforderlich sind.

Passive Angriffe: Hier besteht unmittelbarer Handlungsbedarf.

Harvest-now-decrypt-later: Die akute Bedrohung

Das „Harvest now and decrypt later“-Szenario treibt die PQC-Einführung maßgeblich voran. Sicherheitsbehörden gehen davon aus, dass staatliche Akteure systematisch verschlüsselte Daten sammeln – durch Abfangen von Übertragungen oder Exfiltration nach Systemkompromittierungen – um diese später mit Quantencomputern zu entschlüsseln.

Schutzmaßnahmen für gespeicherte Daten:

Systemhärtung zur Verhinderung von Datenexfiltration
Prinzip der minimalen Berechtigungen
Zeitnahe Sicherheitsupdates
Verdopplung symmetrischer Schlüssellängen bei gesichertem Key Management

Schutz bei Datenübertragung: Die pragmatischste Lösung ist die Implementierung quantensicherer Schlüsselaustauschmechanismen in Kommunikationsprotokollen bei gleichzeitiger Beibehaltung klassischer Handshake-Signaturen und der bestehenden PKI.

Langzeitdokumente und Firmware-Signierung

Kryptografische Signaturen sichern die Authentizität langlebiger Dokumente – von Firmware bis zu rechtsverbindlichen Verträgen. Diese müssen über Jahre oder Jahrzehnte verifizierbar bleiben.

Signierte Firmware ermöglicht kritische Sicherheitsfunktionen wie Secure Boot via Unified Extensible Firmware Interface. Bei der Migration zu PQC-Mechanismen müssen Verifizierungsmethoden erhalten bleiben, die auch auf älteren Systemen funktionieren.

Oracles mehrstufige PQC-Strategie

Oracle verfolgt einen gestaffelten Migrationsansatz, der technische Kontinuität wahrt und Kompatibilitätsprobleme vermeidet:

Kryptografie-Provider: Implementation FIPS-zertifizierter Algorithmen – beginnend mit FIPS 203 ML-KEM (Schlüsselkapselung) und FIPS 204 ML-DSA (Signaturen).

Hybride Schlüsselgenerierung: Kombination klassischer und quantensicherer Mechanismen für gemeinsame Geheimnisse in TLS 1.3, SSH und IKE v2. Das Hybridmodell integriert sich ohne PKI-Änderungen oder Neuzertifizierung. Für CNSA 2.0-regulierte Systeme werden auch nicht-hybride Lösungen unterstützt.

Kerntechnologien: PQC-Implementierung in Java und Oracle Database mit Fokus auf einfache Implementierung und minimale Performance-Einbußen.

Konkrete Umsetzungsschritte

Verschlüsselung ruhender Daten: Migration auf AES-256

Datenübertragung: Umstellung auf hybride Schlüsselaustauschverfahren

Signaturen: FIPS 204 ML-DSA ohne PKI-Modifikation durch direktes Public-Key-Vertrauen

Zertifikate: Schrittweise Einführung reiner PQC-Zertifikate, verankert in privaten CA-PQC-Roots, parallel zu bestehenden ECDSA-Zertifikaten

Firmware-Signierung: Parallelbetrieb klassischer und PQC-Signaturen während der Übergangsphase. Integration von stateless oder stateful Hash-basierten Signaturen in HSMs gemäß CNSA 2.0-Anforderungen.

Bei kontrollierten Vertrauensbasen (wie Oracle Linux) erfolgt direktes Public-Key-Vertrauen ohne vollständige PKI-Infrastruktur.

Fazit: Schrittweise Migration statt Big Bang

Oracles Strategie zeigt: Die PQC-Migration erfordert keinen disruptiven Systemwechsel. Durch hybride Ansätze, schrittweise Algorithmus-Updates und parallele Signaturverfahren lässt sich der Übergang kontrolliert gestalten – bei gleichzeitiger Abwehr der bereits heute akuten Harvest-now-decrypt-later-Bedrohung.

Quelle: Oracle Security Blog

Ähnliche Beiträge