AWS in Switzerland and Austria (Alps)

Die Post-Quanten-Kryptografie: Eine neue Ära der Sicherheit

19. Januar 2026: Der Blog Post wurde mit der neusten NIST Einschätzung und der momentanen PQC-Unterstützung in AWS Services aktualisiert. Zudem wurden die Beispiele zu PQC überarbeitet und die Erwähnung des AWS Post-Quantum Cryptography Migration Plan hinzugefügt.

2. Oktober 2026: Umfassende Aktualisierung. Neu: regulatorischer Kontext mit FINMA-Guidance, Post-Quanten-Signaturen (ML-DSA) in AWS KMS, PQ-Zertifikate in AWS Private CA, sowie der AWS PQC-Migrationsplan mit vier Arbeitsbereichen. Überarbeitet: AWS-LC und FIPS-Zertifizierungen, PQC-Serviceunterstützung (60+ Services), Performance-Hinweise und Client-seitige Implementierung.

Wenn verschlüsselte Daten zwischen zwei Parteien oder Systemen ausgetauscht werden, kommen typischerweise asymmetrische Verschlüsselungsverfahren zum Einsatz. Diese verwenden ein Schlüsselpaar, einen öffentlichen Schlüssel zur Verschlüsselung und einen privaten Schlüssel zur Entschlüsselung. Ein Beispiel dafür ist die RSA-Verschlüsselung. Die Sicherheit von RSA beruht auf der mathematischen Schwierigkeit, grosse Zahlen in ihre Primfaktoren zu zerlegen – ein Prozess, den man als Faktorisierung bezeichnet. Solange diese Faktorisierung nicht effizient möglich ist, bleibt die Verschlüsselungen mit RSA sicher. Allerdings existiert ein Algorithmus, der von dem amerikanischen Mathematiker Peter Shor entwickelt wurde und der Zahlen auf Quantencomputern deutlich schneller faktorisieren könnte, als auf herkömmlichen Computern. Dieser sogenannte Shor-Algorithmus stellt daher eine potenzielle Bedrohung für die RSA-Verschlüsselung dar. Bislang ist das jedoch noch nicht praktisch umsetzbar, da dafür Tausende von fehlerfreien Quantenbits benötigt werden – eine Hürde, die aktuell noch nicht überwunden ist. Das National Institute of Standards and Technology (NIST) empfiehlt, die Migration bis 2035 abzuschliessen und bestimmte anfällige Algorithmen bereits ab 2030 nicht mehr einzusetzen. Daher warnen Experten auch vor sogenannten “harvest now, decrypt later”-Angriffen. Dabei wird verschlüsselter Netzwerkverkehr heute schon aufgezeichnet, um ihn später, wenn leistungsfähige Quantencomputer zur Verfügung stehen, zu entschlüsseln.
Um diese Gefahr zu adressieren, arbeiten Forschungseinrichtungen, Behörden und Unternehmen wie AWS an der Entwicklung von Post-Quanten-Kryptographie. Das amerikanische National Institute of Standards and Technology (NIST) führte seit 2016 einen Standardisierungsprozess durch und hat nun neue Standards für den Austausch von Schlüsseln und Signaturverfahren herausgegeben. Dieser Artikel erklärt das bestehende Problem genauer, beleuchtet die Arbeit von AWS und gibt praktische Lösungsansätze, um die Daten unserer Kunden zu schützen.

Problem und Lösung

Die Verschlüsselung von gespeicherten Daten (data at rest) verwendet hauptsächlich symmetrische Verschlüsselung – also denselben Schlüssel für die Ver- und Entschlüsselung. Das bei AWS eingesetzte AES-GCM Verfahren mit 256-bit Schlüssellänge ist ein weltweit angerkannter Standard und gilt aktuell als sicher gegen Angriffe durch Quantencomputer. AES selbst gilt aktuell als sicher, da die beste bekannte Attacke das Durchprobieren aller möglichen Schlüssel (Brute-Force) ist. Um die Schlüssel für mit AES-256 (2256 Möglichkeiten) verschlüsselte Daten mit heutiger Technologie erraten zu können, würde es eine astronomische Zeit dauern. Beispielsweise würde es mit der kombinierten Rechenleistung der Bitcoin-Mining-Netzwerke etwa 70 Trillionen Jahre dauern, um einen halb so langen AES-128-Schlüssel zu knacken.

Für die sichere Übertragung von Daten (data in transit) werden Protokolle wie TLS oder SSH verwendet, dabei wird der eigentliche Datenverkehr mit symmetrischen Algorithmen verschlüsselt. Die anfängliche Vereinbarung über einen Schlüssel erfolgt jedoch mittels asymmetrischer Verschlüsselung (oder Public-Key-Verschlüsselung). Aufgrund der anfänglich beschriebenen Gefahr, benötigen wir hier neue quantensichere Algorithmen zum Schutz dieser Schlüssel. Zusätzlich müssen wir prüfen, ob die Schlüsselverwaltung oder Zugriffskontrollmechanismen, die das Schlüsselmaterial schützen und auf asymmetrische Kryptografie angewiesen sind, ebenfalls aktualisiert werden müssen.

Um dieser potenziellen Bedrohung zu begegnen, arbeitet AWS seit mehreren Jahren zusammen mit der Kryptografiegemeinschaft an der Entwicklung neuer quantenresistenter Algorithmen. Diese sogenannten “Post-Quanten-Kryptografie” (PQC) Algorithmen basieren auf mathematischen Problemen, die auch für Quantencomputer schwer lösbar sind. Das sorgfältige Auswahlverfahren von NIST hat nun neue Standards für PQ-Verschlüsselung (post-quantum) und digitale Signaturen hervorgebracht und am 13. August 2024 veröffentlicht.

Regulatorischer Kontext und Dringlichkeit

Die Migration zu PQC ist nicht nur eine technische, sondern auch eine regulatorische Notwendigkeit. Über ein Dutzend Volkswirtschaften haben inzwischen formelle PQC-Migrationsrichtlinien veröffentlicht (CISO’s Guide to PQC Migrations). Die Fristen variieren, bewegen sich aber in dieselbe Richtung: Die meisten Regionen verlangen PQC-Bereitschaft für neue Beschaffungen bis 2027, mit vollständigen Migrationsfristen zwischen 2030 und 2035.

Die Eidgenössische Finanzaufsicht (FINMA) in der Schweiz hat dazu die Aufsichtsmitteilung 05/2026 zu Quantum Computing veröffentlicht. Eine Umfrage bei 60 Schweizer Finanzinstituten zeigte: 72% haben noch keine Massnahmen geplant, nur 8% verfügen über einen PQC-Fahrplan. Die FINMA empfiehlt eine vom Verwaltungsrat genehmigte PQC-Strategie bis Mitte 2027 und betont fünf Handlungsfelder: Strategie und Roadmap, Risikoanalyse mit Kryptografie-Inventar, Schutz kritischer Daten vor “Harvest Now, Decrypt Later”, Crypto-Agility als Designprinzip, sowie die vertragliche Absicherung der PQC-Bereitschaft externer Dienstleister. Bemerkenswert: Die FINMA empfiehlt explizit hybride Verschlüsselungsverfahren – genau den Ansatz, der hier mit der Kombination von ECDH und ML-KEM verfolgt wird.

Der Beitrag von Amazon

Amazon brachte sich aktiv am Standardisierungsprozess von NIST ein. Darüber hinaus ist das Unternehmen an Projekten und Arbeitsgruppen wie der Internet Engineering Task Force (IETF), dem ETSI Quantum Safe Cryptography Technical Committee und der Open Quantum Safe Initiative beteiligt. Amazon-Mitarbeiter haben zudem zum SPHINCS+-Algorithmus (SLH-DSA) beigetragen, der von NIST als einer der finalen digitalen Signaturalgorithmen ausgewählt wurde.

2014 entdeckten Forscher einen schwerwiegenden Fehler (Heartbleed) in einer älteren OpenSSL-Bibliothek, der das Knacken verschlüsselter TLS-Verbindungen ermöglichte. Die Referenzimplementierung von OpenSSL wuchs auf 500’000 Codezeilen und damit immer komplexer und fehleranfälliger. Dies bewog Amazon 2015 ihre eigene TLS-Implementierung namens s2n-tls (signal to noise) zu lancieren. s2n-tls umfasst nur 6’000 Codezeilen und hat drei externe Sicherheitsprüfungen bestanden. Seit 2017 verschlüsselt s2n-tls den gesamten Netzwerkverkehr von Amazon S3. Das AWS-Kryptographie-Team unterhält auch eine eigene kryptographische Bibliothek (AWS-LC) mit Implementierungen von Algorithmen für TLS. Die Amazon libcrypto verfügt über mehrere FIPS 140-3 Zertifizierungen von NIST (#4631, #4759, #4816) und war weltweit die erste kryptographische Open-Source-Bibliothek, die ML-KEM in eine FIPS 140-3 Validierung einschloss. Die AWS-LC beinhaltet die quanten-sicheren Algorithmen nach NIST-Standard für den Schlüsselaustausch (ML-KEM, FIPS 203) sowie für digitale Signaturen (ML-DSA, FIPS 204 und SLH-DSA, FIPS 205). Zuletzt ergänzte s2n-quic die Sammlung von Open-Source-Verschlüsselungsbibliotheken von AWS. QUIC ist ein verschlüsseltes Transportprotokoll, das die Grundlage von HTTP/3 bildet.

Alternative AWS open source Bibliotheken

Alternative AWS open source Bibliotheken

Breite PQC-Unterstützung in AWS Services

AWS hat die Unterstützung für ML-KEM mittlerweile auf über 60 AWS Services ausgeweitet. Die vollständige und stets aktuelle Liste finden Sie auf der Seite Shared Responsibility for Post-Quantum Confidentiality. Die PQC-Aktivierung erfolgt nach drei Kategorien:

Transparent (automatisch für aktualisierte Clients): Die meisten AWS Services, darunter AWS KMS, ACM, Secrets Manager, IAM, STS, S3, CloudFront, SNS, SQS und viele weitere, unterstützen hybrid PQ-Schlüsselaustausch automatisch, sobald der Client ML-KEM anbietet. Für Endbenutzer-Verbindungen wie Amazon CloudFront ist keine Kundenaktion erforderlich: PQC wird automatisch für alle TLS-Sicherheitsrichtlinien aktiviert.

Opt-in (Konfiguration durch den Kunden): Bei Services, die kundeneigene Ressourcen verwalten, muss eine PQC-fähige Sicherheitsrichtlinie explizit ausgewählt werden:

  • Application und Network Load Balancer: PQC-fähige TLS-Listener-Policy auswählen
  • Amazon API Gateway: PQC-fähige TLS-Sicherheitsrichtlinie für REST APIs konfigurieren
  • AWS Transfer Family: PQC-fähige Sicherheitsrichtlinie für SFTP-Server konfigurieren
  • Amazon Aurora MySQL: Datenbankversion auf mindestens MySQL 8.4.8 aktualisieren

Migration empfohlen: Classic Load Balancer unterstützen kein TLS 1.3 und können nicht PQ-fähig gemacht werden. AWS empfiehlt die Migration auf Application oder Network Load Balancer.

Transparenz und Governance: Um den Einsatz von PQC nachverfolgen zu können, protokolliert AWS CloudTrail bei unterstützten Services bereits die TLS-Version und die verwendete Cipher Suite in den tlsDetails der API-Aufrufe. Die Protokollierung des verwendeten Schlüsselaustauschverfahrens wird in Kürze folgen. Zusätzlich können Kunden über IAM-Richtlinien Mindestanforderungen an TLS-Sicherheitsrichtlinien bei der Erstellung und Aktualisierung von Ressourcen durchsetzen.

Implementierung auf Client-Seite

Die bisherigen Abschnitte beschreiben, was auf der AWS-Seite bereitsteht. Doch bei jeder TLS-Verbindung sind zwei Seiten beteiligt. Wenn Ihre Anwendungen AWS-Services direkt über APIs ansprechen – etwa über ein AWS SDK in Java, Python oder Rust – dann muss auch die Client-Seite ML-KEM unterstützen, damit der quanten-sichere Schlüsselaustausch zustande kommt. Ohne dieses Update fällt die Verbindung automatisch auf klassische Kryptografie zurück. Je nach SDK ist ein Upgrade der gebündelten Kryptobibliothek, ein Wechsel auf OpenSSL 3.5+ oder die Aktivierung eines Feature-Flags erforderlich. Details zu den spezifischen Anforderungen der einzelnen SDKs finden Sie unter Enabling hybrid post-quantum TLS.

Wichtig: Die Unterstützung für CRYSTALS-Kyber (den Vorgänger von ML-KEM) wird 2026 von allen AWS-Service-Endpunkten entfernt. Kunden, die ihre SDKs nicht aktualisieren, fallen automatisch auf klassische Schlüsselvereinbarung zurück, was bedeutet, dass ihre Verbindungen nicht mehr quanten-sicher sind.

Testverbindung mit quanten-sicherem Schlüsseltausch

Um zu überprüfen, ob Post-Quanten-Kryptographie tatsächlich aktiv ist, können Sie verschiedene Testmethoden nutzen. Die folgenden zwei Beispiele zeigen unterschiedliche Ansätze: Das erste Beispiel demonstriert die automatische Aktivierung bei Services wie CloudFront, wo PQC ohne zusätzliche Konfiguration funktioniert, sobald der Client (Browser) dies unterstützt. Das zweite Beispiel zeigt die manuelle Verifikation mittels OpenSSL auf der Kommandozeile, was z.B. beim Einsatz von Boto3 (Python) SDK verwendet wird.

Beispiel: Webseite hinter CloudFront mit Google Chrome

Amazon CloudFront unterstützt bereits Post-Quanten-Kryptographie. Sie können dies einfach im Chrome Browser (ab Version 131) überprüfen:

  1. Öffnen Sie eine Webseite, die hinter CloudFront gehostet wird (z.B. eine AWS-Dokumentationsseite)
  2. Öffnen Sie die Developer Tools unter View-Developer-Developer Tools
  3. Wählen Sie den Reiter “Privacy und Security”
  4. Im Abschnitt “Verbindung” sehen Sie die verwendeten Verschlüsselungsalgorithmen
  5. Bei aktiviertem PQC erscheint “X25519Kyber768” oder “X25519MLKEM768” als Key Exchange Mechanism
Google Chrome Verbindung via Amazon Cloudfront

Google Chrome Verbindung via Amazon Cloudfront

Beispiel: Manuelle Verifikation mit OpenSSL

Um zu überprüfen, ob ein AWS-Endpunkt Post-Quanten-Kryptographie unterstützt, können Sie OpenSSL ab Version 3.5.0 verwenden:

# Bestätigen Sie, dass OpenSSL mindestens Version 3.5.0 ist
$ openssl --version
# Verbindung testen - die Ausgabe sollte "Negotiated TLS1.3 group: X25519MLKEM768" enthalten
$ openssl s_client -connect kms.eu-central-2.amazonaws.com:443 -servername kms.eu-central-2.amazonaws.com

Beispiel Ausgabe:

Connecting to 16.63.90.182
CONNECTED(00000006)
...
Negotiated TLS1.3 group: X25519MLKEM768
SSL handshake has read 6276 bytes and written 1585 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Protocol: TLSv1.3
...

Eine Schritt-für-Schritt-Anleitung zur Verwendung von Amazons eigener Kryptobibliothek aws-lc und der TLS-Implementierung s2n-tls für hybride Post-Quanten-Verbindungen mit ML-KEM finden Sie in unserem Artikel “Testing TLS Connections with Post-Quantum Cryptography using s2nc“, der die praktische Konfiguration und Verifikation von Post-Quanten-Kryptographie demonstriert.

Post-Quanten-Signaturen mit ML-DSA

Neben dem quanten-sicheren Schlüsselaustausch hat AWS die Unterstützung für post-quanten-sichere digitale Signaturen eingeführt. Seit Juni 2025 unterstützt AWS KMS den ML-DSA-Algorithmus (FIPS 204) für Signaturoperationen innerhalb FIPS 140-3 Level 3 zertifizierter HSMs. Kunden können aus drei Schlüsselspezifikationen wählen:

Schlüsselspezifikation NIST-Sicherheitsstufe Öffentlicher Schlüssel Signatur
ML_DSA_44 Stufe 1 (äquivalent 128-bit) 1’312 Bytes 2’420 Bytes
ML_DSA_65 Stufe 3 (äquivalent 192-bit) 1’952 Bytes 3’309 Bytes
ML_DSA_87 Stufe 5 (äquivalent 256-bit) 2’592 Bytes 4’627 Bytes

Die Erstellung und Verwendung erfolgt über die vertrauten AWS KMS APIs (CreateKey, Sign, Verify):

aws kms create-key --key-spec ML_DSA_65 --key-usage SIGN_VERIFY

Dieser Schritt ist besonders relevant für Organisationen, die langlebige Vertrauensanker (Roots of Trust) für Firmware-, Software- oder Dokumentensignaturen benötigen. Zum Beispiel Firmware auf Satelliten, IoT-Geräten oder Gaming-Konsolen: Hier können kryptographische Signaturen nach der Installation nicht einfach aktualisiert werden.

Post-Quanten-Zertifikate mit AWS Private CA

Seit November 2025 unterstützt AWS Private CA post-quanten-sichere digitale Zertifikate. Kunden können damit PQ-Zertifikatsketten für ihre private PKI aufbauen und so die Grundlage für eine vollständig quanten-sichere Zertifikatsinfrastruktur legen.

Der AWS PQC-Migrationsplan

AWS verfolgt einen mehrschichtigen Migrationsplan mit vier parallelen Arbeitsbereichen. Die PQC-Migration erfolgt nach dem bekannten Shared-Responsibility-Modell: Einige PQC-Funktionen werden transparent für alle Kunden aktiviert, andere stehen als Optionen zur Verfügung, die Kunden je nach ihren Anforderungen implementieren können.

Arbeitsbereich 1: Inventar, Standards und Planung
Laufende Arbeit an der kryptographischen Bestandsaufnahme, Entwicklung neuer Standards und Migrationsplanung. AWS hat dabei entschieden, die Verschlüsselung während der Übertragung (in transit) zu priorisieren, da die bei AWS eingesetzte 256-bit symmetrische Verschlüsselung für ruhende Daten (at rest) nach aktuellem Konsens nicht durch Quantencomputer gefährdet ist.

Arbeitsbereich 2: PQ-Schlüsselaustausch auf öffentlichen AWS-Endpunkten
Integration von ML-KEM auf AWS-Service-Endpunkten. Über 60 Services unterstützen bereits hybrid PQ-Schlüsselaustausch.

Arbeitsbereich 3: PQ-Signaturen für langlebige Vertrauensanker
ML-DSA ist in AWS KMS verfügbar. AWS Private CA unterstützt PQ-Zertifikate.

Arbeitsbereich 4: PQ-Signaturen für sitzungsbasierte Authentifizierung
Die Integration von PQ-Signaturen in Zertifikate für die TLS-Authentifizierung erfordert branchenweite Standardisierung und Interoperabilitätstests (IETF, CA/Browser Forum). Dieser Arbeitsbereich ist noch in Arbeit.

Krypto-Agilität als langfristiges Ziel

Die PQC-Migration sollte nicht als einmaliges Compliance-Projekt betrachtet werden. Das Ziel ist der Aufbau einer dauerhaften Krypto-Agilität: die organisatorische Fähigkeit, Protokolle, Algorithmen und Schlüssellängen bei Bedarf zu rotieren. Starke Patching-Disziplin, zuverlässige CI/CD-Pipelines und automatisiertes Lebenszyklusmanagement sind Fähigkeiten, die über die PQC-Migration hinaus wertvoll sind. Eine Organisation, die Algorithmen auf Abruf rotieren kann, ist auch besser gegen andere sich schnell entwickelnde Situationen gerüstet.

Zusammenfassung

Die Post-Quanten-Kryptografie erfordert Handeln – nicht irgendwann, sondern jetzt. Beginnen Sie mit einer Bestandsaufnahme Ihrer kryptographischen Abhängigkeiten. Aktualisieren Sie Ihre AWS SDKs und Browser, um den hybriden PQ-Schlüsselaustausch zu aktivieren. Und nutzen Sie die unten stehenden Ressourcen, um Ihre eigene PQC-Roadmap aufzubauen.

AWS steht Ihnen als Partner zur Seite: mit über 60 Services, die bereits hybriden PQ-Schlüsselaustausch unterstützen, mit ML-DSA für quanten-sichere Signaturen, und mit einem klaren Migrationsplan, der Ihnen Orientierung gibt.AWS Post-Quantum Cryptography Migration Plan

Weiterführende Informationen:

Strategie und Migration:

Technische Implementierung:

Referenzseiten:

Beratung: