Résumé

  • RFC 10042 définit trois méthodes SSH hybrides ML-KEM/ECDH et une dérivation unique issue de deux secrets éphémères.
  • La construction lie un échange de clés, tandis que l’acceptation de la clé d’hôte et les décisions relatives à l’utilisateur restent des contrôles locaux distincts.

Dans SSH, une signature n’est utile qu’avec la question qu’elle signe. RFC 10042 remplace l’ancien format de l’échange de clés par une paire de messages hybrides. Le client envoie SSH_MSG_KEX_HYBRID_INIT et une chaîne C_INIT qui réunit une clé publique ML-KEM et une clé publique classique. Le serveur renvoie SSH_MSG_KEX_HYBRID_REPLY, sa clé publique d’hôte K_S, une chaîne S_REPLY faite d’un chiffré ML-KEM et d’une clé publique classique, puis la signature du hachage d’échange.

Deux secrets naissent de cette séquence : K_PQ côté ML-KEM et K_CL côté ECDH. RFC 10042 impose leur encodage à longueur fixe, puis les hache pour produire K, la matière utilisée par la dérivation SSH. Elle impose aussi une nouvelle paire de clés éphémères ECDH et ML-KEM par connexion et interdit la réutilisation de l’aléa des chiffrés ML-KEM. Ce sont des règles précises pour une session donnée, pas un certificat général de la personne qui se connecte ou de la machine atteinte.

Les vérifications de forme ont la même portée. Le serveur doit contrôler la longueur attendue de C_INIT avant l’encapsulation ; le client doit contrôler celle de S_REPLY avant la décapsulation. Un échec de longueur ou de décapsulation mène à une déconnexion de type échec d’échange de clés. L’événement établit qu’une condition du protocole n’a pas été satisfaite. Il ne permet pas d’inférer l’identité de l’hôte, le nom d’un utilisateur, l’autorisation demandée ou l’effet d’une commande.

Le point qui se perd le plus facilement est K_S. Le message hybride porte bien une clé publique d’hôte et une signature qui lie cette clé au transcript. Mais l’architecture SSH sépare cette opération de la manière dont un client sait que la clé appartient à l’hôte recherché. RFC 4251 prévoit une base locale associant nom d’hôte et clé, ou une association certifiée par une autorité acceptée. RFC 4253 demande au client de vérifier K_S avec un certificat ou une base locale, tout en indiquant qu’une acceptation sans vérification reste vulnérable aux attaques actives. RFC 10042 ne remplace ni cette provenance ni ce jugement local.

Les trois noms enregistrés — mlkem768nistp256-sha256, mlkem1024nistp384-sha384 et mlkem768x25519-sha256 — sont eux aussi des identifiants de mécanisme, non des comptes rendus d’exécution. Une configuration peut annoncer un nom ; un SSH_MSG_KEXINIT peut le proposer ; le registre IANA peut le documenter. Il faut encore établir la compatibilité de l’autre partie, la sélection effective, les contrôles de longueur, la dérivation achevée et l’acceptation de la clé d’hôte. Même cela précède l’authentification de l’utilisateur, que SSH place dans un protocole séparé au-dessus du transport.

Le hachage d’échange fournit une bonne frontière de preuve. Il incorpore les identifiants client et serveur, les deux charges KEXINIT, K_S, les deux messages hybrides et K. Il lie donc une clé d’échange à des octets déterminés. Il ne contient pas la règle locale déterminant quels identifiants utilisateurs sont acceptés, quel service est permis ou quelle action est exécutée. RFC 4251 réserve explicitement au serveur et à sa politique locale le choix des méthodes d’authentification et des accès autorisés.