Dieses Diagramm veranschaulicht, warum eine mit einem symmetrischen Datenschlüssel verschlüsselte Datenbank dennoch anfällig für Quantenangriffe sein kann – nämlich durch den Public-Key-Mechanismus, der diesen Schlüssel etabliert, überträgt oder schützt. Zudem werden Abhängigkeiten aufgezeigt, die leicht übersehen werden, insbesondere bei der CI/CD-Signierung und der SSH-Administration; hier steht weniger der Verlust der Vertraulichkeit (zu einem späteren Zeitpunkt) im Vordergrund als vielmehr der Verlust der Authentizität.
Sobald die Architektur alle Abhängigkeiten identifiziert hat, ist das angestrebte Ergebnis eine fundierte Migrationsentscheidung – und nicht bloß die pauschale Behauptung, ein System sei „quantensicher“ (quantum-ready). Wir müssen erkennen, welche kryptografischen Primitive durch den Shor-Algorithmus gefährdet sind, zwischen Schlüsseletablierung und Signaturen unterscheiden sowie jedes gefährdete Primitiv mit dem geschützten Asset und der jeweiligen Vertrauensgrenze (Trust Boundary) verknüpfen. Im August 2024 hat das NIST drei grundlegende PQC-Algorithmen standardisiert: FIPS 203 ML-KEM für die Schlüsseletablierung, FIPS 204 ML-DSA für digitale Signaturen und FIPS 205 SLH-DSA für zustandslose, hash-basierte Signaturen.
In späteren Lektionen werden vier praktische Kompetenzen vermittelt:
Krypto-Agilität bezeichnet die Fähigkeit, kryptografische Algorithmen, Schlüssel und zugehörige Abhängigkeiten auszutauschen, ohne inakzeptable Unterbrechungen oder einen Verlust der Interoperabilität zu verursachen. Sie ist eine Eigenschaft des Gesamtsystems – einschließlich Konfiguration, Zertifikatsverwaltung, Herstellerunterstützung und Protokollaushandlung – und nicht eine Eigenschaft, die allein durch einen Algorithmus bereitgestellt wird.
Welche Kontaktpunkte bergen das Risiko eines künftigen Vertraulichkeitsverlusts bei gespeicherten Daten, und bei welchen besteht nach dem „Q-Day“ vor allem die Gefahr gefälschter Identitäten oder einer Beeinträchtigung der Integrität? Der Vergleich trennt diese Entscheidungen voneinander.
Ein in einem langfristig aufbewahrten Backup verschlüsselter Kundendatensatz bleibt auch heute noch unlesbar, selbst wenn ein Angreifer das Backup vor Jahren aus dem Objektspeicher kopiert hat. Der Angreifer benötigte hierfür keinen Zugriff auf die Datenbank, die Anwendung oder den Verschlüsselungsschlüssel. Wurde der Datenverschlüsselungsschlüssel des Backups mittels RSA- oder Elliptische-Kurven-Kryptografie (ECC) ausgehandelt oder geschützt, könnte ein zukünftiger, kryptanalytisch relevanter Quantencomputer diesen Schlüssel wiederherstellen und die gespeicherten Daten offenlegen. Für Verteidiger stellt sich daher nicht die Frage, wann ein Endpunkt gehackt wird. Entscheidend ist vielmehr, ob heute verschlüsselte Daten auch dann noch Vertraulichkeitsschutz benötigen, wenn eine Quanten-Kryptanalyse praktikabel wird.
Dasselbe Problem gilt für TLS-Datenverkehr, der über einen Netzwerkpfad mitgeschnitten wurde. Eine Sitzung, die durch herkömmlichen Public-Key-Schlüsselaustausch geschützt ist, kann die Vertraulichkeit von customer_id=48291 während der Laufzeit wahren; dennoch könnte eine aufgezeichnete Sitzung später entschlüsselbar werden, wenn ihr Public-Key-Schutz einem Quantenangriff zum Opfer fällt. Hierbei handelt es sich um das Szenario „Harvest Now, Decrypt Later“ (jetzt erfassen, später entschlüsseln): Geschützte Daten werden heute gesammelt, um sie zu einem späteren Zeitpunkt zu entschlüsseln, wenn leistungsfähigere Rechenkapazitäten verfügbar sind. Das Risiko hängt dabei von der Dauer ab, über die die Vertraulichkeit der Daten gewahrt bleiben muss, und nicht allein vom voraussichtlichen Zeitpunkt der Verfügbarkeit eines Quantencomputers.
Q-Day
Der Q-Day bezeichnet den Zeitpunkt, an dem ein kryptanalytisch relevanter Quantencomputer (CRQC) die Public-Key-Annahmen, auf denen ein System basiert, praktisch aushebeln kann. Für den Systembetreiber stellt der Q-Day eine Planungsgrenze dar, nicht die Vorhersage eines konkreten Kalenderdatums. Das NIST weist darauf hin, dass die Schätzungen zur Verfügbarkeit von CRQCs stark variieren, während die Implementierung kryptografischer Umstellungen in Produkten, Diensten und Infrastrukturen erfahrungsgemäß Jahre in Anspruch nimmt.
Dieser Kurs behandelt die Bedrohung gezielt und präzise. Der Shor-Algorithmus gefährdet RSA- und Elliptische-Kurven-Verfahren (Public-Key-Verfahren), die für den Schlüsselaustausch und digitale Signaturen eingesetzt werden. Dies bedeutet jedoch nicht, dass jedes verschlüsselte Byte gleichermaßen anfällig wird. Faktoren wie symmetrische Verschlüsselung, Hash-Verfahren, Schlüsselspeicherung, Protokollkonfiguration, Zertifikatslebenszyklus und Datenspeicherdauer entscheiden weiterhin darüber, ob eine gegen Quantencomputer anfällige Public-Key-Abhängigkeit ein tatsächlich schützenswertes Gut (Asset) gefährdet.
Da Backups und TLS-Datenströme lediglich zwei Zugangswege zu demselben System darstellen, beginnt die Migration mit der Identifizierung aller Stellen, an denen Public-Key-Kryptografie Vertrauen schafft. Bei einem typischen Dienst greift ein Browser auf ein Web-Frontend zu, das Frontend ruft eine API auf und die API liest Daten aus einer Datenbank. Zur Architektur gehören zudem Backup-Speicher, administrative Zugriffe, das Signieren von Build-Artefakten, Protokolldaten (Logs) und externe Integrationen. Eine kryptografische Bestandsaufnahme muss für jeden dieser Pfade erfassen, welche Protokolle, Algorithmen, Bibliotheken, Zertifikate, Schlüsselinhaber und Datenspeicherfristen jeweils zum Einsatz kommen.
TLS nutzt üblicherweise RSA oder ECC zur Authentifizierung sowie – abhängig von der gewählten Protokollkonfiguration – für den Schlüsselaustausch. JWT-Signaturschlüssel können RSA- oder Elliptische-Kurven-Signaturen verwenden, damit eine API Herkunft und Integrität eines Tokens überprüfen kann. Code-Signierungszertifikate stellen sicher, dass ein Release-Artefakt von einem autorisierten Herausgeber stammt. SSH-Host-Keys authentifizieren den Server, auf den Administratoren zugreifen. Da diese Kontrollmechanismen unterschiedlichen Sicherheitszielen dienen, lässt sich ihr Austausch nicht durch einen pauschalen Algorithmenwechsel bewerkstelligen.
Die nachstehende Architektur trennt die Punkte, an denen Public-Key-Verfahren zum Einsatz kommen, von den Mechanismen des symmetrischen Schutzes – eine Unterscheidung, die auch in der Bestandsaufnahme gewahrt bleiben muss: