Erweiterte Post-Quantum-Funktionen von SSH in Red Hat Enterprise Linux

Der Übergang zur Post-Quanten-Kryptografie (PQC) ist in Red Hat Enterprise Linux (RHEL) bereits in vollem Gange. Im Mai 2025 stellte RHEL 10 Post-Quanten-Schlüsselaustauschalgorithmen in drei wichtigen Kryptografie-Libraries (OpenSSL, GnuTLS und NSS) bereit, sodass der Post-Quanten-Schlüsselaustausch in TLS 1.3-Verbindungen möglich ist. RHEL 10.1 folgte, legte die neuen Schlüsselaustauschalgorithmen als Standard in TLS fest und führte Post-Quanten-Signaturen für RPM-Pakete ein.

Das Secure Shell (SSH) Protokoll wurde dabei nicht vernachlässigt. RHEL 10 wird mit OpenSSH 9.9 ausgeliefert und unterstützt zwei hybride Post-Quanten-Methoden zum Schlüsselaustausch: sntrup761x25519-sha512 kombiniert den klassischen X25519-Schlüsselaustausch mit dem gitterbasierten optimierten NTRU Prime-Algorithmus (SNTRUP) und mlkem768x25519-sha256 kombiniert X25519 mit dem vom US-amerikanischen National Institute of Standards and Technology (NIST) standardisierten Schlüssel-Encapsulation-Mechanismus auf Modul-Lattice-Basis (ML-KEM). Ab RHEL 10.1 wird Letzteres von OpenSSH beim Herstellen von Verbindungen bevorzugt, sofern Sie nichts anderes konfiguriert haben.

Neuerungen für SSH in RHEL 10.2

Weitere PQC-Funktionen von SSH wurden in RHEL 10.2 integriert.

Post-Quanten-SSH-Schlüsselaustausch im FIPS-Modus

Die IETF-SSHM-Arbeitsgruppe (Internet Engineering Task Force Secure Shell Maintenance) stellt derzeit den RFC-Entwurf für mlkem768x25519-sha256 fertig, und der Algorithmus wird zunehmend von verschiedenen SSH-Implementierungen übernommen. Der Entwurf spezifiziert jedoch auch zwei weitere hybride Schlüsselaustauschalgorithmen: mlkem768nistp256-sha256 und mlkem1024nistp384-sha384. Diese kombinieren ML-KEM-Varianten mit dem ECDH-Schlüsselaustausch (Elliptic-Curve Diffie-Hellman) über vom NIST empfohlene Kurven (P-256 und P-384) anstelle von Curve25519.

Da ML-KEM und ECDH über P-256/P-384 allesamt FIPS-genehmigt sind, stellen wir mlkem768nistp256-sha256 und mlkem1024nistp384-sha384 als die einzigen zwei Post-Quanten-FIPS-kompatiblen SSH-Schlüsselaustauschalgorithmen in Red Hat Enterprise Linux 10.2 zur Verfügung. Obwohl die Upstream-OpenSSH-Verantwortlichen beschlossen haben, diese beiden zusätzlichen Hybride nicht zu implementieren, können Kunden die Post-Quanten-Kryptographie in SSH dank der von Red Hat Entwicklern bereitgestellten Downstream-Patches für OpenSSH bereits im FIPS-Modus nutzen.

Unterstützung für den Post-Quanten-Schlüsselaustausch in libssh

Diese hybriden Schlüsselaustauschkonstruktionen sind nun auch in libssh 0.12.0 (der SSH-C-Library) verfügbar. In Übereinstimmung mit dem OpenSSH-Verhalten bevorzugen SSH-Clients und -Server, die gegen libssh erstellt wurden, in RHEL 10.2 standardmäßig den Schlüsselaustauschalgorithmus mlkem768x25519-sha256. Das bedeutet, dass sich Kunden, die benutzerdefinierte libssh-basierte Server betreiben, durch ein einfaches Upgrade vor „Harvest now, decrypt later“-Angriffen schützen können.

Zukünftige Möglichkeiten für SSH

Weitere PQC-Funktionen befinden sich noch im Standardisierungsprozess, und Red Hat ist daran beteiligt.

Reiner ML-KEM-Schlüsselaustausch und Post-Quanten-SSH-Schlüssel

Wir beobachten die laufenden Bemühungen, die Verwendung des reinen (nicht hybriden) ML-KEM-Schlüsselaustauschs in SSH zu standardisieren. Die IETF-SSHM-Arbeitsgruppe hat den aktuellen Entwurf noch nicht angenommen, da kein Konsens darüber besteht, ob dieser angemessen ist (Gegner argumentieren, dass ML-KEM nicht ausgereift genug sei).

Die Verwendung von ML-DSA (einer NIST-standardisierten Familie von Post-Quanten-Signaturalgorithmen) in SSH wird ebenfalls diskutiert, wobei es mehrere konkurrierende RFC-Entwürfe gibt: draft-rpe-ssh-mldsa und draft-sfluhrer-ssh-mldsa streben beide eine Standardisierung der reinen ML-DSA-Nutzung für öffentliche SSH-Schlüssel an, während draft-sun-ssh-composite-sigs und draft-josefsson-ssh-ed25519mldsa65 auf die Standardisierung von zusammengesetzten ML-DSA-Signaturen (z. B. in Kombination mit klassischen EdDSA-Signaturen) abzielen. Die Implementierung einer dieser Optionen würde es SSH-Clients und -Hosts ermöglichen, sich mit Post-Quanten-Public-Keys zu authentifizieren, was sie vor Man-in-the-Middle-Angriffen mit Quantencomputern schützt.

GSSAPI-Schlüsselaustausch mit Post-Quanten-Kryptografie

Schließlich arbeiten wir daran, den GSSAPI-Schlüsselaustausch mit hybriden PQC-Methoden (nämlich den drei hybriden ML-KEM-Methoden) zu standardisieren und diesen in OpenSSH und libssh zu implementieren. Der von Red Hat vorgeschlagene RFC-Entwurf baut auf RFC 4462 und RFC 8732 auf. Die Übernahme wird die Kerberos-Authentifizierung in SSH quantensicher machen.

Fazit

Mit der Veröffentlichung von Red Hat Enterprise Linux 10.2 ist der Post-Quanten-SSH-Schlüsselaustausch standardmäßig aktiviert. Dies gilt unabhängig davon, ob Sie im FIPS-Modus arbeiten oder benutzerdefinierte SSH-Anwendungen auf Basis von libssh verwenden.  Wir laden Sie ein, Ihre Systeme auf die neueste Version von RHEL 10 zu aktualisieren, um „Harvest now, decrypt later“-Bedrohungen zu mindern.

Die Engineers von Red Hat bleiben in der IETF und in den Upstream-Communities aktiv, um die nächste Phase des quantensicheren SSH mitzugestalten. Dies umfasst die Unterstützung von Post-Quantum-Hostschlüsseln und die Post-Quantum-GSSAPI-Authentifizierung (Kerberos). Sobald die neuen SSH-Standards ausgereift sind und ein Konsens besteht, werden wir diese in zukünftigen Releases von Red Hat Enterprise Linux weiter implementieren und unterstützen.