Q-Day-Countdown: Neue Daten zur Einführung der Post-Quanten-Kryptografie

Lange galt die Bedrohung durch Quantencomputer als Zukunftsszenario. Doch die Umstellung von Netzwerkressourcen – IT, IoT, OT, c und andere – auf Post-Quanten-Kryptografie (PQC) rückt näher, als viele Verantwortliche annehmen.

Mit dem näher rückenden „Q-Day“, dem Zeitpunkt, an dem Quantencomputer asymmetrische Verschlüsselung praktisch brechen können, wächst der Handlungsdruck. Unternehmen müssen gefährdete Systeme identifizieren, priorisieren und Migrationspläne entwickeln. Weltweite Roadmaps sehen Übergangsfristen für PQC zwischen 2030 und 2035 vor, insbesondere für kritische Infrastrukturen.

Das Sicherheitsunternehmen Forescout hat kürzlich eine patentierte Technologie vorgestellt, die quantenunsichere verschlüsselte Kommunikation in Netzwerken erkennt. Parallel dazu veröffentlichte das Unternehmen eine Analyse zum Stand der PQC-Einführung im Internet. Die im Frühjahr erhobenen Daten zeigten: Nur 6 Prozent aller SSH-Server – beziehungsweise 20 Prozent der Server mit OpenSSH – unterstützten bereits PQC. Bei HTTPS-Servern nutzten 19 Prozent TLSv1.3, das PQC-Algorithmen ermöglichen könnte.

Die aktualisierte Untersuchung, die nun Daten bis Ende August sowie Informationen aus Forescouts „Device Cloud“ umfasst, zeigt deutliche Veränderungen. Die PQC-Unterstützung steigt, vor allem durch neue OpenSSH-Versionen und die Standardisierung relevanter Algorithmen. Inzwischen unterstützen 8,5 Prozent aller SSH-Server – und 26 Prozent der OpenSSH-Server – den PQC-Schlüsselaustausch. Der Anteil von TLSv1.3 bleibt unverändert bei 19 Prozent.

Deutliche Unterschiede zeigen sich zwischen den Gerätetypen: Während mehr als 40 Prozent der IT-Systeme mit OpenSSH bereits PQC-fähige Versionen einsetzen, liegt der Anteil bei IoT-Geräten bei 20 Prozent, bei OT- und Netzwerkkomponenten bei 11 Prozent und bei medizinischen IoMT-Geräten bei nur 2 Prozent.

Auch zwischen den Branchen bestehen Unterschiede. Keine der untersuchten Branchen erreicht eine PQC-Unterstützung von mehr als 50 Prozent bei OpenSSH-Geräten. Besonders niedrige Werte verzeichnen Fertigung, Öl und Gas sowie Bergbau – Sektoren mit vielen nicht verwalteten Geräten. Die höchsten Raten wurden im Bereich der professionellen und geschäftlichen Dienstleistungen beobachtet.

Forescout diskutiert auf Basis dieser Ergebnisse, welche Entwicklungen Unternehmen in naher Zukunft erwarten können und welche Schritte erforderlich sind, um Risiken frühzeitig zu mindern.

Wichtige Erkenntnisse

• Die Unterstützung der Post-Quanten-Kryptografie (PQC) für SSH-Server nimmt zu
  • 8,5 % aller SSH-Server
  • 26 % aller OpenSSH-Server
• Die Einführung von TLSv1.3, das PQC unterstützt, hat in den letzten Monaten nicht zugenommen
  • Die Einführung von TLSv1.3 bleibt bei 19 %.
  • TLSv1.2 – das PQC nicht unterstützt – stieg von 43 % auf 46 %.
• Nicht verwaltete Geräte bleiben zurück, und es ist noch ein langer Weg, bis die meisten quantensicher sind.
  • IoT-, OT-, IoMT- und Netzwerkgeräte weisen eine deutlich geringere Einführung von PQC für SSH auf als herkömmliche IT-Assets.
  • Die PQC-Migration endet nicht mit TLS und OpenSSH.
• Die Akzeptanz in der Industrie ist ungleichmäßig – insbesondere in Branchen mit vielen nicht verwalteten Geräten.
  • Die Fertigungsindustrie, die Öl- und Gasindustrie sowie der Bergbau weisen die niedrigsten PQC-Akzeptanzraten auf.
  • Professionelle und geschäftliche Dienstleistungen weisen die höchsten Akzeptanzraten auf.

Empfehlungen

• Informieren Sie Ihr Team über die NIST-Richtlinien „Migration to PQC” (Umstellung auf PQC), die sich auf CSF 2.0 und NIST SP 800-53 beziehen.
• Klassifizieren Sie Ihre Daten nach Langlebigkeit und Sensibilität.
• Erstellen Sie eine Bestandsaufnahme der Assets in Ihrem Netzwerk, die PQC unterstützen oder nicht unterstützen.
• Korrelieren Sie diese Bestandsaufnahme mit Kontextinformationen zu diesen Assets, um Risiken zu verstehen.

Die PQC-Migration schreitet in Richtung standardisierter Algorithmen voran

Ende August waren im Internet mehr als 175 Millionen SSH-Hosts aktiv, die verschiedene Schlüsselaustauschalgorithmen (KEX) zur Einrichtung von Sitzungsschlüsseln für Ende-zu-Ende-verschlüsselte Kommunikation unterstützten.

Wie bereits in den früheren Erhebungen zeigte sich, dass die beliebtesten PQC-KEX-Algorithmen – siehe Tabelle unten – weiterhin SNTRUP (Standard-KEX von OpenSSH zwischen den Versionen 9.0 und 9.9) und ML-KEM (Standard-KEX von OpenSSH ab Version 10) sind.

Drei zentrale Beobachtungen lassen sich daraus ableiten:

1. Zunehmende PQC-Unterstützung:
Die Zahl der Server mit PQC-Unterstützung stieg von 11,5 Millionen im April auf nahezu 15 Millionen im August – ein Anstieg um rund 30 Prozent. Der Anteil an allen Servern erhöhte sich von 6,2 auf 8,5 Prozent.

2. Wachstum standardisierter Algorithmen:
Während im April noch mehrere experimentelle Algorithmen mit Herstellerkennzeichnungen wie „@openquantumsafe“ oder „@amazon“ verbreitet waren, sind diese inzwischen nahezu verschwunden. Einzelne Einträge zu Kyber und FrodoKEM bestehen zwar noch, nehmen jedoch ab, da das größte Wachstum bei den standardisierten PQC-KEX zu verzeichnen ist.
Wie die Auswertung zeigt, wuchs sntrup761x25519-sha512 zwischen April und August um 17 Prozent, während mlkem768x25519-sha256 im gleichen Zeitraum um 323 Prozent zulegte.

3. Einfluss neuer OpenSSH-Versionen:
Das Wachstum ist vor allem auf die Aktualisierung der OpenSSH-Versionen zurückzuführen. Der Anteil älterer Versionen (7.0 bis 8.9), die vor der Einführung der standardmäßigen PQC-Unterstützung veröffentlicht wurden, sank von 75 auf 70 Prozent. Gleichzeitig stieg der Anteil der Versionen 9.0 bis 10, die SNTRUP und anschließend ML-KEM als Standard-KEX enthalten, von 21 auf 26 Prozent.

Nicht verwaltete Geräte bleiben zurück

Auf Grundlage der Daten aus der Device Cloud von Forescout wurde untersucht, welche Gerätetypen und Branchen bereits quantensichere OpenSSH-Versionen einsetzen.

Die Auswertung zeigt deutliche Unterschiede: Während 42 Prozent der IT-Geräte OpenSSH-Versionen mit PQC-Unterstützung verwenden, liegt der Anteil bei IoT-Geräten bei 20 Prozent, bei Netzwerk- und OT-Geräten bei 11 Prozent und bei IoMT-Geräten bei lediglich 2 Prozent.

Diese Verteilung überrascht kaum, da IT-Systeme in der Regel einfacher zu aktualisieren sind. Besonders kritisch ist jedoch die Situation bei Netzwerkgeräten wie Routern, Firewalls und VPN-Appliances. Diese sind häufig direkt mit dem Internet verbunden und werden per SSH ferngesteuert – ein potenzielles Einfallstor für Angreifer, die darüber privilegierten Zugriff erlangen könnten. Solche Geräte stehen zunehmend im Fokus von Bedrohungsakteuren, die sie für Spionagezwecke oder zur Vorpositionierung nutzen. Das Risiko, dass Anmeldedaten aufgrund schwacher Verschlüsselung während der Übertragung kompromittiert werden, gilt daher als besonders besorgniserregend.

Unter den IoT-, OT- und IoMT-Geräten weisen bestimmte Funktionsbereiche die niedrigsten PQC-Akzeptanzraten auf – darunter physische Zugangskontrollsysteme (1 %), VoIP-Geräte (1 %) und Kommunikationssysteme im Gesundheitswesen (2 %).

Auch der Blick auf die Branchen zeigt ein ähnliches Bild: In keiner der untersuchten Branchen liegt die PQC-Unterstützung bei OpenSSH-Geräten über 50 Prozent. Sektoren, die stark auf nicht verwaltete Geräte angewiesen sind, verzeichnen tendenziell die niedrigsten Akzeptanzraten – ein Ergebnis, das die bisherigen Beobachtungen bestätigt.

Was die Zukunft bringt

Der Anteil der SSH-Server im Internet mit standardmäßigem PQC-KEX wächst weiter, allerdings deutlich langsamer als zwischen 2022 und Anfang 2024, als die ersten OpenSSH-Versionen mit PQC-Unterstützung erschienen. Die Marke von 20 bis 25 Prozent wurde nun überschritten – aktuell liegt der Anteil bei 26 Prozent –, doch bis die Mehrheit der SSH-Server quantensicher ist, ist noch ein weiter Weg.

Ähnliche Entwicklungen zeigen sich bei TLS. Die IETF hat PQC-Unterstützung ausschließlich für TLSv1.3 eingeführt. Positiv ist, dass TLSv1.3 inzwischen die zweithäufigste Version im Internet ist (im April lag sie noch an dritter Stelle). Relativ gesehen bleibt ihr Anteil am Datenverkehr jedoch bei 19 Prozent, während TLSv1.2 – das keine PQC-Unterstützung bietet – von 43 auf 46 Prozent zulegte.

Diese Zahlen verdeutlichen, dass die Umstellung auf PQC langwierig und komplex sein wird. Die Gründe dafür sind vielfältig:

• Migration über TLS und OpenSSH hinaus: Neben diesen Protokollen müssen auch andere Standardprotokolle wie IPSEC/IKEv2 und WireGuard für VPN-Tunnel migriert werden. Darüber hinaus existieren zahlreiche OT- oder IoMT-spezifische Protokolle, die unterschiedliche Migrationsansätze erfordern. Bei diesen Geräten war die größte Herausforderung bislang die Einführung von Verschlüsselung überhaupt.

• Eingeschränkte Aktualisierungsmöglichkeiten bei eingebetteten Geräten: Viele Geräte nutzen veraltete Krypto-Bibliotheken. Selbst wenn populäre Anwendungen und Bibliotheken wie OpenSSH oder OpenSSL PQC unterstützen, können nicht alle Geräte einfach auf die neuen Versionen aktualisiert werden. Im Rahmen der Project-Memoria-Forschung wurden über 50 in eingebetteten Geräten verwendete TCP/IP-Stacks katalogisiert. Während viele auf gut gepflegte Bibliotheken wie mBedTLS setzen, verwenden einige eigene Implementierungen oder veraltete Bibliotheken. Jüngste Untersuchungen zeigen, dass die geplante PQC-Unterstützung in mehreren kryptografischen Bibliotheken uneinheitlich umgesetzt wird.

Was ist zu tun?

Die neuen Erkenntnisse zeigen: Geräte, die leicht aktualisiert werden können, werden schnell auf PQC umgestellt, doch das Wachstum wird langsamer, sobald die einfachen Implementierungen abgeschlossen sind. Unternehmen müssen daher ihre Risiken kennen und Strategien zu deren Minderung entwickeln.

Der erste Schritt zur PQC-Migration ist eine Bestandsaufnahme der Assets im Netzwerk – welche PQC unterstützen und welche nicht. Dabei kann die Technologie von Forescout unterstützen.

Das NIST veröffentlicht im Rahmen seines Projekts „Migration zu PQC“ Richtlinien, darunter ein Whitepaper, das Fähigkeiten zur kryptografischen Erkennung dem Cybersecurity Framework 2.0 und NIST SP 800-53 zuordnet. Diese Dokumente helfen Unternehmen, die eigene Vorbereitung zu prüfen und die Migration zu planen.

Wichtig ist, die Risiken im Kontext zu verstehen: Ein TLS-Handshake mit RSA-2048 kann ungefährlich sein, wenn er kurzlebige Daten in einer geschützten Umgebung sichert, während ein veralteter FTP-Server mit sensiblen Dokumenten ein strategisches Risiko darstellt. Das Ziel ist, Risiken klar zu erfassen, nicht Panik zu verbreiten.

Eine pragmatische Roadmap umfasst drei Schritte:

1. Daten klassifizieren: Nach Sensibilität und Langlebigkeit. Kritische Informationen wie Anmeldedaten oder langlebige Token müssen Vorrang haben.

2. Infrastruktur aufrüsten: Veraltete Kryptografie erkennen, Risiken abbilden und Sicherheitskontrollen wie Segmentierung implementieren.

3. Agilität einplanen: „Quantensicher“ bedeutet nur Schutz gegen bekannte Angriffe. Krypto-Stacks sollten Schlüsselrotation und Algorithmuswechsel von Anfang an unterstützen, um künftigen Entwicklungen zu begegnen.

Lesen Sie auch

---