Chaque connexion SSH que vous lancez aujourd'hui depuis votre iPhone pourrait être enregistrée et stockée silencieusement quelque part. L'objectif de cet enregistrement n'est pas de déchiffrer maintenant, mais d'attendre le jour où les ordinateurs quantiques seront suffisamment matures pour tout déchiffrer rétroactivement en masse. L'industrie de la sécurité a donné à ce type d'attaque un nom très parlant : « enregistrer maintenant, déchiffrer plus tard » (Harvest Now, Decrypt Later).

La bonne nouvelle, c'est que la défense est désormais une norme officielle : le NIST a finalisé en 2024 l'algorithme d'encapsulation de clés post-quantique ML-KEM (FIPS 203), et OpenSSH l'a intégré par défaut dans son échange de clés. Aujourd'hui, NeoServer apporte ML-KEM sur iOS — votre iPhone peut initier de véritables connexions SSH post-quantiques, et ce sans aucune configuration.

« Enregistrer maintenant, déchiffrer plus tard » : pourquoi s'en soucier dès maintenant

La confidentialité du SSH classique repose sur des problèmes mathématiques classiques comme ECDH ou RSA. Ils sont suffisamment sûrs face aux ordinateurs actuels, mais une fois qu'un ordinateur quantique exécute l'algorithme de Shor, ces problèmes sont cassés efficacement. Le vrai problème, c'est le décalage temporel :

1. L'enregistrement a lieu aujourd'hui. Le Wi-Fi des aéroports et des cafés, un routeur compromis, n'importe quel maillon de la chaîne peut stocker le trafic chiffré — à un coût quasi nul pour celui qui enregistre.
2. Le déchiffrement aura lieu dans le futur. Dès qu'un ordinateur quantique suffisamment puissant existera, chaque échange de clés classique enregistré aujourd'hui pourra être cassé rétroactivement — sans que vous ayez besoin de commettre la moindre erreur à ce moment-là.
3. Une session SSH déchiffrée l'est entièrement. Votre mot de passe sudo, les fichiers de configuration et les clés affichés via cat, les tokens dans vos scripts de déploiement, la topologie de votre réseau interne : tout apparaît en clair.

Pour les administrateurs de serveurs, les utilisateurs de NAS et les ingénieurs d'exploitation, le trafic SSH est précisément la cible d'enregistrement à la plus forte valeur à long terme. Et la stratégie « on verra quand les ordinateurs quantiques existeront vraiment » est irréversible pour le trafic déjà enregistré.

ML-KEM en trois minutes

ML-KEM (Module-Lattice-based Key Encapsulation Mechanism, mécanisme d'encapsulation de clés basé sur les réseaux modulaires) est la norme cryptographique post-quantique FIPS 203 finalisée par le NIST en août 2024, héritière de l'algorithme Kyber. Sa sécurité repose sur des problèmes mathématiques definis sur les réseaux (lattices) — problèmes pour lesquels aucun algorithme quantique connu à ce jour n'offre de solution efficace.

Il ne fait qu'une seule chose, mais c'est justement la plus cruciale : l'échange de clés. À l'établissement de la connexion, les deux parties négocient une clé de session via ML-KEM ; ensuite, même si un ordinateur quantique rejouait l'intégralité du trafic, il ne pourrait pas reconstituer cette clé.

Deux faits worth knowing :

• Depuis la version 9.9 (septembre 2024), OpenSSH active par défaut l'échange de clés hybride mlkem768x25519-sha256. Il combine ML-KEM-768 avec le classique X25519 : deux problèmes mathématiques protègent simultanément la même session, et casser l'un ne suffit pas à déchiffrer. La plupart des distributions Linux récentes et le serveur SSH de macOS le prennent déjà en charge par défaut depuis environ un an.
• Apple déploie massivement le chiffrement post-quantique. iMessage a introduit la protection post-quantique avec le protocole PQ3, et iOS 26 va plus loin en chiffrant avec ML-KEM les communications entre l'iPhone et l'Apple Watch. Entre votre téléphone et votre montre, c'est déjà du post-quantique — et votre client SSH, lui ?

L'iPhone est souvent le maillon faible de la chaîne

Le serveur est prêt par défaut, mais le client reste souvent à la traîne : la plupart des clients SSH iOS n'offrent à ce jour que l'échange de clés classique. D'où une situation absurde : le serveur prend parfaitement en charge la négociation post-quantique, mais la poignée de main est rétrogradée côté téléphone vers un algorithme classique.

Or le téléphone est précisément l'appareil le plus exposé : Wi-Fi de café, d'aéroport, d'hôtel, réseaux douteux, connexions lancées à la va-vite. Sur votre Mac, vous prenez peut-être la peine d'ajouter une couche WireGuard ; cette rapide connexion SSH depuis l'iPhone est souvent en direct, sans protection.

NeoServer comble cette lacune. À la connexion, NeoServer négocie automatiquement en priorité mlkem768x25519-sha256 :

• Serveur compatible → session post-quantique immédiate, toute la connexion est quantiquement sûre dès la poignée de main
• Serveur plus ancien → repli en douceur vers les algorithmes classiques, la connexion fonctionne normalement, sans interrompre le moindre flux de travail
• Zéro configuration : aucun réglage à modifier, effectif dès la mise à jour de l'app

Vérifiez en 30 secondes si votre serveur est prêt

Exécutez sur le serveur (cela fonctionne aussi dans le terminal de NeoServer) :

ssh -Q kex | grep mlkem
# Si la sortie contient mlkem768x25519-sha256, c'est pris en charge

Pour voir le résultat de la négociation de vos propres yeux, ajoutez -vv lors d'une connexion depuis un ordinateur de bureau :

ssh -vv user@your-server 2>&1 | grep "kex:"
# debug1: kex: algorithm: mlkem768x25519-sha256

Si la première commande ne renvoie rien, c'est que le OpenSSH du serveur est antérieur à la version 9.9 ; une mise à jour du système ou d'OpenSSH suffira à l'obtenir. Ensuite, en vous connectant depuis NeoServer, la négociation basculera automatiquement vers ML-KEM.

Au-delà de l'échange de clés : le modèle de sécurité de NeoServer

L'échange de clés post-quantique résout le problème du « trafic enregistré » ; NeoServer ne fait aucun compromis sur les autres aspects :

• Les clés privées restent uniquement sur votre iPhone, protégées par Face ID / Touch ID ; en cas de besoin multi-appareils, la synchronisation passe par votre iCloud privé
• SSH Agent Forwarding : le serveur distant « emprunte » temporairement les clés de votre téléphone pour s'authentifier, sans jamais écrire la clé privée sur le serveur — voir la présentation détaillée précédente
• Capacités d'authentification complètes : mot de passe, clé privée, 2FA, serveur de rebond (bastion), failover, proxy Socks5
• Zéro statistique tierce, zéro SDK publicitaire : NeoServer ne communique avec aucun serveur que vous n'avez pas configuré ; vos données n'appartiennent qu'à vous

À cela s'ajoutent : Mosh pour garder la connexion lors des changements de réseau, des sessions tmux/zellij récupérables après déconnexion, SFTP, supervision de serveurs, gestion Docker/Podman et exécution de scripts en lot. NeoServer n'est pas seulement « un terminal qui supporte ML-KEM », c'est un poste de travail d'exploitation mobile complet sur iPhone.

Pour qui ?

• Passionnés de serveurs domestiques et utilisateurs de NAS (Synology, QNAP, TrueNAS, etc.)
• Administrateurs de sites et ingénieurs d'exploitation
• Développeurs et programmeurs
• Ceux qui gèrent des nœuds de calcul IA et des serveurs cloud
• Et toutes celles et ceux qui estiment qu'un « déchiffrement par relecture dans dix ans » ne devrait pas menacer le trafic d'aujourd'hui

Quantiquement sûr dès la prochaine connexion

Ce qui rend l'attaque « enregistrer maintenant, déchiffrement plus tard » redoutable, c'est son asymétrie : le défenseur n'a qu'à mettre à jour une seule fois sa poignée de main aujourd'hui, tandis que l'attaquant peut conserver indéfiniment le trafic enregistré hier. Votre serveur est prêt depuis longtemps par défaut ; il ne manque qu'un client iOS compatible ML-KEM.

Ouvrez l'App Store et recherchez NeoServer, ou rendez-vous directement sur l'App Store pour le télécharger — pour que votre prochaine connexion SSH depuis votre iPhone soit quantiquement sûre dès la poignée de main.