Neuerungen bei der Post-Quanten-Kryptografie in RHEL 10.1

Im Mai 2025 wurde Red Hat Enterprise Linux 10 (RHEL) mit den ersten Schritten zur Post-Quanten-Kryptografie (PQC) ausgeliefert, um vor Angriffen von Quantencomputern zu schützen, die Angriffe auf bestehende klassische kryptografische Algorithmen wie RSA und elliptische Kurven ermöglichen. Kryptografisch relevante Quantencomputer (CRQC) sind noch nicht bekannt. Das heißt aber nicht, dass das Risiko null ist. So benötigen etwa „Harvest now, decrypt later“-Angriffe jetzt keinen Quantencomputer mehr, es muss nur einer zur Verfügung stehen, bevor die gespeicherten, verschlüsselten Daten ihren Wert verlieren. Je nach den übertragenen Daten können Jahrzehnte vergehen.

Um sich auf eine Zukunft mit Quantencomputern vorzubereiten, verbessert RHEL 10.1 den Schutz vor „Harvest now, decrypt later“-Angriffen und führt Post-Quanten-Signaturen für seine Pakete ein.

Der nächste Abschnitt behandelt Änderungen an PQC in Transport Layer Security (TLS), gefolgt von einem Abschnitt, in dem eine Änderung der standardmäßigen Kryptografierichtlinien von RHEL erläutert wird. Wussten Sie, dass RHEL die erste große Linux-Distribution ist, die ihre Pakete mit hybriden Post-Quanten-Schlüsseln signiert?

Der dritte Abschnitt behandelt die Details dieser Änderungen, bevor die empfohlenen nächsten Schritte für Nutzende und Drittanbieter von Software erläutert werden.

Post-Quanten-Kryptografie in TLS

TLS kann Post-Quanten-Kryptografie an zwei Stellen verwenden: Schlüsselaustausch zum Schutz vor Angriffen vom Typ „Harvest now, decrypt later“ (Jetzt ernten, später entschlüsseln) und Signaturen, die Machine-in-the-Middle-Angriffe mit Quantencomputern verhindern. Mit der Veröffentlichung von RHEL 10.1 ist für Anwendungen, die OpenSSL, GnuTLS, NSS oder die Programmiersprache Go verwenden, die Unterstützung für den Post-Quanten-Schlüsselaustausch standardmäßig aktiviert.

Die OpenSSL-, GnuTLS- und NSS-Kryptografie-Bibliotheken unterstützen außerdem Signaturen und TLS-Zertifikate mit dem Module-Lattice-Based Digital Signature Algorithm (ML-DSA), einem vom NIST standardisierten PQC-Algorithmus. Beachten Sie, dass derzeit keine öffentlichen Zertifizierungsstellen (Certificate Authorities, CAs) Post-Quanten-Kryptografie anbieten. Private CAs oder selbstsignierte Zertifikate können heute mit ML-DSA erstellt werden.

In RHEL 10.0 wurde diese Funktionalität als Technology Preview veröffentlicht, da sich Standards und Implementierungen schnell weiterentwickeln. Dies ändert sich nun: Post-Quanten-Kryptografie mit Module-Lattice-Based Key Encapsulation Mechanism (ML-KEM) und ML-DSA in TLS ist allgemein verfügbar und wird vollständig unterstützt in Go, OpenSSL, GnuTLS und NSS.

Im Vorfeld von RHEL 10.1 haben die Entwicklungsteams von Red Hat einen produktweiten Test des PQC-Schlüsselaustauschs und der PQC-Zertifikate durchgeführt. Dadurch konnten mehrere Probleme identifiziert werden, die von den Paketverwaltern in Upstream Open Source-Projekten und Downstream in RHEL behoben wurden. Wir empfehlen Ihnen, noch heute mit dem Testen des hybriden PQC-Schlüsselaustauschs in Ihren TLS-Bereitstellungen zu beginnen und Pläne für duale klassische/PQC-TLS-Zertifikatsserver zu erstellen (siehe „Erstellen eines Post-Quanten-TLS-Zertifikats“).

PQC nach DEFAULT-Richtlinie

Kryptografieeinstellungen auf RHEL werden mithilfe von systemweiten kryptografischen Richtlinien verwaltet, wobei DEFAULT die Standardrichtlinie ist. In RHEL 10.1 wurde diese Richtlinie geändert, um Post-Quanten-Kryptografie standardmäßig zu aktivieren und zu bevorzugen. Dies bedeutet, dass TLS- und SSH-Verbindungen von und zu RHEL 10.1 oder höher automatisch den Post-Quanten-Schlüsselaustausch verwenden, sofern verfügbar. Diese beiden Protokolle sind weit verbreitet und machen wahrscheinlich den Großteil der verschlüsselten Datenübertragungen aus, wodurch sich die Sicherheitslage erheblich verbessert.

Anwendungen auf RHEL 9.7, die auf OpenSSL oder NSS basieren, können auch PQC in TLS verwenden, wenn das systemweite kryptografische Richtlinienmodul „PQ“ mit sudo update-crypto-policies --set DEFAULT:PQ aktiviert ist.

Führen Sie den Befehl update-crypto-policies --show aus, um die von Ihrem System verwendete Richtlinie zu überprüfen.

Paketaktualisierungen mit Post-Quanten-Signaturen

Schließlich haben die Entwicklerinnen und Entwickler von Red Hat daran gearbeitet, einen Schutz vor Angriffen durch Quantencomputer für unsere Software-Distributionspfade einzuführen. Dies ist wichtig, weil Red Hat über diese Pfade zukünftige Verbesserungen in der Post-Quanten-Transition bereitstellt.

Red Hat Enterprise 10 verwendet die Sequoia-PGP-Implementierung von OpenPGP zur Verifizierung von Paketsignaturen. Eine Spezifikation zur Verwendung von PQC in OpenPGP befindet sich in den letzten Zügen, und Red Hat hat zu ihrer Implementierung in Sequoia-PGP beigetragen, das jetzt als Vorabversion verfügbar ist. Einige Betriebsumgebungen sehen behördliche Anforderungen für die Signierung von PQC-Software in kurzer Zeit vor. Daher ist diese Implementierung nach gründlichen Tests in RHEL 10.1 enthalten.

Im selben Projekt erhielten die Tools sq-cryptoki und sq Unterstützung für den Zugriff auf Post-Quanten-Schlüssel über PKCS#11. Dies ermöglicht die Integration mit Hardware-Sicherheitsmodulen. Red Hat hat seine Signierinfrastruktur modernisiert, einen Post-Quanten-Signierschlüssel erstellt, der einen Hybrid aus ML-DSA-87 und Ed448 verwendet, und damit begonnen, seine RPM-Pakete mit diesem Schlüssel zu signieren. RHEL ist die erste und derzeit einzige große Linux-Distribution, die diesen Meilenstein erreicht hat.

Das erste signierte Post-Quanten-Paket war ipmitool-1.8.19-10.el10_1 in RHBA-2025:23156:

# dnf download ipmitool
ipmitool-1.8.19-10.el10_1.aarch64.rpm                                                                                                                                                                          # rpm -Kv ipmitool-1.8.19-10.el10_1.aarch64.rpm | head -3
ipmitool-1.8.19-10.el10_1.aarch64.rpm:     
	Header V6 ML-DSA-87+Ed448/SHA512 Signature, key ID 05707a62: OK     	
	Header V4 RSA/SHA256 Signature, key ID fd431d51: OK

Beachten Sie, dass dieses Paket auch weiterhin mit unserem RSA-Schlüssel signiert ist. Systeme, die das RPM 6-Headerformat und OpenPGP v6-Signaturen verstehen, verifizieren sowohl die RSA- als auch die PQC-Signaturen. Ältere Systeme validieren nur die klassische RSA-Signatur.

Fazit

Red Hat hat bei seiner Post-Quanten-Transition wichtige Schritte unternommen, um unsere Kunden auf kommende Risiken und regulatorische Anforderungen vorzubereiten. TLS mit hybridem ML-KEM-Schlüsselaustausch befindet sich nicht mehr in der Technology Preview und kann Angriffe nach dem Prinzip „Harvest now, decrypt later“ abmildern. Die Unterstützung für ML-DSA-Zertifikate und -Signaturen in den zentralen Kryptografie-Bibliotheken von RHEL, OpenSSL, GnuTLS und NSS, ist jetzt ebenfalls allgemein verfügbar.

In Einklang mit den jüngsten Brancheninitiativen (z. B. dem European Cyber Resilience Act) für standardmäßige Sicherheit wurde die Standardkonfiguration geändert, um Post-Algorithmen in TLS und SSH zu aktivieren und zu bevorzugen. Weitere Protokolle werden in Zukunft folgen. Wir empfehlen allen Nutzenden, den PQC-Schlüsselaustausch einzuführen und duale klassische/PQC-TLS-Zertifikat-Setups mit ihren TLS-Servern zu testen. Sie möchten vielleicht auch erfahren, wie Sie Ihre Organisation auf die Zukunft der Quantentechnologie vorbereiten.

Schließlich ist RHEL die erste große Distribution, die ihren Paketen hybride Post-Quanten-Signaturen hinzufügt. Für unsere Partner hat mein Kollege Jakub Jelen dokumentiert, wie RPM-Pakete mit Post-Quanten-Schlüsseln signiert werden. Die Integration mit Hardware-Sicherheitsmodulen über PKCS#11 3.2 für die RPM-Signierung ist heute möglich. Unsere Support- und Engineering-Teams können Ihnen dabei helfen.

Go unterstützt derzeit nur ML-KEM ab Version 1.24. ML-DSA-Unterstützung wird in einer zukünftigen Version erwartet.