Amélioration des capacités post-quantiques de SSH dans Red Hat Enterprise Linux

La transition vers la cryptographie post-quantique (PQC) est déjà bien avancée dans Red Hat Enterprise Linux (RHEL). En mai 2025, RHEL 10 a fourni des algorithmes d'échange de clés post-quantiques dans trois grandes bibliothèques de cryptographie (OpenSSL, GnuTLS et NSS), rendant l'échange de clés post-quantique utilisable dans les connexions TLS 1.3. La version RHEL 10.1 a suivi, en définissant les nouveaux algorithmes d'échange de clés par défaut dans TLS et en introduisant des signatures post-quantiques pour les paquets RPM.

Le protocole SSH (Secure Shell) n'a pas été délaissé. RHEL 10 a été livré avec OpenSSH 9.9, qui prend en charge deux méthodes d'échange de clés post-quantiques hybrides : sntrup761x25519-sha512 combine l'échange de clés X25519 classique avec l'algorithme SNTRUP (Streamlined NTRU Prime) basé sur les réseaux, et mlkem768x25519-sha256 combine X25519 avec le mécanisme d'encapsulation de clés basé sur les réseaux modulaires (ML-KEM) normalisé par le NIST (National Institute of Standards and Technology). À partir de RHEL 10.1, OpenSSH privilégie cette dernière méthode pour l'établissement de connexions, sauf configuration contraire.

Nouveautés pour SSH dans RHEL 10.2

D'autres fonctionnalités PQC de SSH ont été intégrées à RHEL 10.2.

Échange de clés SSH post-quantique en mode FIPS

Le projet de RFC pour mlkem768x25519-sha256 est actuellement en cours de finalisation par le groupe de travail SSHM (Secure Shell Maintenance) de l'IETF (Internet Engineering Task Force), et l'algorithme est de plus en plus adopté par diverses implémentations SSH. Cependant, le projet spécifie également deux autres algorithmes d'échange de clés hybrides : mlkem768nistp256-sha256 et mlkem1024nistp384-sha384. Ceux-ci combinent des variantes ML-KEM avec l'échange de clés ECDH (Elliptic-curve Diffie-Hellman) sur des courbes recommandées par le NIST (P-256 et P-384) au lieu de Curve25519.

Comme ML-KEM et ECDH sur P-256/P-384 sont tous approuvés par les normes FIPS, nous rendons mlkem768nistp256-sha256 et mlkem1024nistp384-sha384 disponibles en tant qu'uniques algorithmes d'échange de clés SSH post-quantiques compatibles FIPS dans Red Hat Enterprise Linux 10.2. Bien que les mainteneurs d'OpenSSH en amont aient décidé de ne pas implémenter ces deux hybrides supplémentaires, les clients Red Hat peuvent commencer à utiliser la cryptographie post-quantique dans SSH en mode FIPS grâce aux correctifs d'OpenSSH fournis par les développeurs de Red Hat.

Prise en charge de l'échange de clés post-quantique dans libssh

Ces constructions d'échange de clés hybrides arrivent enfin dans libssh 0.12.0 (la bibliothèque C SSH). S'alignant sur le comportement d'OpenSSH, les clients et serveurs SSH basés sur libssh privilégient désormais l'algorithme d'échange de clés mlkem768x25519-sha256 par défaut dans RHEL 10.2. Cela signifie que les personnes utilisant des serveurs personnalisés basés sur libssh peuvent se protéger contre les attaques de type « harvest now, decrypt later » par une simple mise à jour.

Possibilités futures pour SSH

D'autres fonctionnalités PQC sont encore en cours de normalisation, et Red Hat participe à ce processus.

Échange de clés ML-KEM pur et clés SSH post-quantiques

Nous suivons les efforts en cours pour normaliser l'utilisation de l'échange de clés ML-KEM pur (non hybride) dans SSH. Le projet actuel n'est pas encore adopté par le groupe de travail SSHM de l'IETF, car il n'existe pas de consensus sur sa pertinence (les opposants estimant que ML-KEM n'est pas assez mature).

L'utilisation de ML-DSA (une famille d'algorithmes de signature post-quantique normalisée par le NIST) dans SSH est également en cours de discussion, avec plusieurs projets de RFC concurrents : draft-rpe-ssh-mldsa et draft-sfluhrer-ssh-mldsa cherchent tous deux à normaliser l'utilisation de ML-DSA pur pour les clés publiques SSH, tandis que draft-sun-ssh-composite-sigs et draft-josefsson-ssh-ed25519mldsa65 visent à normaliser les signatures ML-DSA composites (associées, par exemple, aux signatures EdDSA classiques). La mise en œuvre de l'un de ces projets permettrait aux clients et aux hôtes SSH de s'authentifier à l'aide de clés publiques post-quantiques, les protégeant contre les attaques de l'homme du milieu réalisées par des ordinateurs quantiques.

Échange de clés GSSAPI avec cryptographie post-quantique

Enfin, nous travaillons sur la normalisation de l'échange de clés GSSAPI avec des méthodes PQC hybrides (à savoir les trois méthodes ML-KEM hybrides) et sur son implémentation dans OpenSSH et libssh. Le projet de RFC proposé par Red Hat s'appuie sur les RFC 4462 et RFC 8732, et son adoption sécurisera l'authentification Kerberos dans SSH face à la menace quantique.

Conclusion

Le lancement de Red Hat Enterprise Linux 10.2 active par défaut l'échange de clés SSH post-quantique, que les équipes travaillent en mode FIPS ou utilisent des applications SSH personnalisées basées sur libssh.  La mise à niveau des systèmes vers la version de Red Hat Enterprise Linux 10 la plus récente permet de réduire les menaces de type « harvest now, decrypt later ».

Les ingénieurs de Red Hat restent actifs au sein de l'IETF et des communautés upstream pour aider à définir la prochaine phase du protocole SSH résistant aux attaques quantiques, notamment la prise en charge des clés d'hôte post-quantiques et de l'authentification GSSAPI (Kerberos) post-quantique. À mesure que les nouvelles normes SSH parviennent à maturité et font l'objet d'un consensus, Red Hat continuera de les implémenter et de les prendre en charge dans les futures versions de Red Hat Enterprise Linux.