Groupe DH partagé, secrets neufs : pourquoi l’attaque coûte moins cher

Les paramètres du groupe sont publics par conception, et c’est précisément cette publicité qui les rend faciles à ignorer. En Diffie-Hellman sur corps fini, le module et le générateur sont partagés, alors que les exposants privés et les clés de session qui en résultent ne le sont pas. L’étape coûteuse d’une attaque par crible de corps de nombres dépend du groupe et non d’un seul échange, si bien qu’un groupe faible unique utilisé partout devient une responsabilité commune. Qualifier les paramètres de publics est exact et hors sujet, car le coût réutilisé est celui de l’attaque contre ce groupe.

La moitié publique n’est pas la moitié vulnérable, et c’est là le piège

Le demi-argument habituel dit que les paramètres sont publiés dans une norme, donc un attaquant les connaît déjà et les cacher ne changerait rien. Les deux propositions sont vraies et aucune ne découle de l’autre. Un groupe par défaut livré est public, et un groupe privé que vous avez généré la semaine dernière est aussi visible par quiconque termine la poignée de main. Le secret n’a jamais été le contrôle ; la force et la validation le sont.

Ce qui change, c’est le nombre d’endroits qui partagent la même faiblesse. Une organisation qui génère son propre groupe de 2048 bits paie son propre coût d’attaque, tandis qu’un choix par défaut de protocole retenu par des millions amortit un coût unique sur tous. C’est en ce sens qu’un groupe peu courant n’est pas automatiquement meilleur. Un groupe inhabituel trop petit n’est qu’un secret partagé plus petit avec moins d’yeux dessus.

La validation compte autant que la taille. Un pair qui envoie un module à petits facteurs, ou un module qui n’a pas la forme attendue par le protocole, peut divulguer des informations sur l’exposant privé même quand la longueur en bits paraît respectable. Les bibliothèques qui rejettent les paramètres malformés à l’entrée font un vrai travail, et c’est pourquoi l’analyse de paramètres écrite à la main est un mauvais endroit pour économiser des efforts.

Ce que le précalcul rapporte réellement à un attaquant

Le crible de corps de nombres comporte une étape qui ne dépend que du nombre premier, et sa sortie est réutilisable contre chaque échange qui emploie ce nombre premier. C’est tout le mécanisme derrière l’inquiétude historique : la partie coûteuse est payée une fois, et le coût marginal de chaque session suivante baisse. Des exposants neufs protègent encore chaque échange individuel d’un observateur passif, tant que le groupe est assez grand pour rendre le criblage infaisable. Les deux affirmations sont compatibles, et la plupart des discussions sur ce sujet viennent du fait de retenir l’une et d’abandonner l’autre.

Le travail Logjam de 2015 a démontré une rétrogradation vers Diffie-Hellman à 512 bits de qualité export et estimé ce que coûterait l’attaque de groupes plus grands et largement réutilisés avec des ressources importantes. La démonstration était concrète, les estimations étaient des estimations, et ni l’une ni les autres n’étaient la preuve qu’une session VPN précise ait été déchiffrée.

Citez ce travail pour le mécanisme et pour la rétrogradation démontrée, non comme une mesure de votre déploiement. Les vieilles statistiques sur le nombre de serveurs partageant un groupe par défaut décrivent l’internet de cette année-là, pas un réseau que vous pouvez inspecter aujourd’hui. Ce qui mérite d’être retenu, c’est la question : vos appareils négocient-ils encore un groupe petit ou faiblement validé ?

Normalisé n’est pas synonyme de faible

La RFC 7919 définit des groupes de corps fini nommés pour que les deux extrémités s’accordent sur un groupe par identifiant et appliquent une politique cohérente. Être normalisé est un avantage, car cela supprime l’ambiguïté de négociation et permet à une implémentation de refuser des tailles non prises en charge. Un groupe nommé n’est faible que lorsque sa taille passe sous la politique que vous prétendez suivre, et non parce qu’il figure dans un document. La même logique s’applique aux groupes de courbes elliptiques, qui ont une structure et des modes de défaillance différents.

Gardez les constructions séparées lorsque vous raisonnez à leur sujet. Une conclusion sur Diffie-Hellman sur corps fini ne dit rien de X25519, et une conclusion sur un groupe MODP à 1024 bits ne dit rien d’un groupe à 3072 bits. La politique de force est par mécanisme, par taille et par version de protocole, et c’est pourquoi la formule cryptographie forte n’est pas une affirmation vérifiable.

L’authentification est l’autre moitié, et elle ne remplace rien. Un groupe fort sans vérification du pair laisse un attaquant au milieu, et un certificat valide ne peut pas sauver un échange à 768 bits. Examinez-les comme deux lignes indépendantes, puis confirmez que les deux sont réellement négociées.

Lisez le groupe négocié sur une connexion réelle

Lisez le groupe négocié depuis l’appareil plutôt que depuis le modèle de configuration. Les modèles décrivent l’intention, et la valeur intéressante est celle sur laquelle les deux extrémités se sont accordées lors de la dernière poignée de main. Sur un point de terminaison IPsec, la sortie d’état imprime généralement la proposition retenue, y compris le groupe MODP.

Capturez cette ligne avant et après un changement de politique, et conservez les deux dans le journal des changements. La comparaison est la preuve.

ipsec statusall | grep -Ei "proposal|ESP|IKE"
openssl dhparam -in /etc/vpn/dh3072.pem -check -noout

Si l’état montre encore l’ancien groupe après le changement, la connexion n’a pas renégocié et la modification de configuration n’a rien prouvé. Redémarrez le pair ou effacez l’association de sécurité, puis relisez l’état. Une politique appliquée uniquement aux nouvelles connexions laissera les tunnels de longue durée sur les anciens paramètres tant qu’ils restent actifs.

Vérifiez le groupe et l’identité du pair séparément

Séparez ce que le groupe protège de qui se trouve à l’autre bout. Enregistrez la méthode d’échange de clés, la taille du groupe et la méthode d’authentification comme trois champs, car ils échouent indépendamment. Un tunnel qui a négocié un groupe de 3072 bits mais accepte n’importe quel certificat n’est pas le même risque qu’un tunnel qui épingle un pair et utilise un groupe de 2048 bits.

Écrivez les critères d’acceptation avant le début de la revue, pour que le résultat soit une comparaison et non une opinion. Une taille minimale de groupe par version de protocole, une liste d’autorisation de groupes nommés et une vérification obligatoire du pair suffisent à rendre la décision mécanique. L’ambiguïté de cette liste est ce qui transforme une revue en discussion, et les discussions ne sont pas corrigées. Alors la sortie est une liste de points de terminaison qui échouent à une règle énoncée.

ipsec statusall | grep -Ei "peer|auth|cert"
openssl s_client -connect vpn.acme.example:443 -brief -cipher 'DHE-RSA-AES256-GCM-SHA384'

Bouclez la boucle en relisant les valeurs négociées après la remédiation. Un fichier de configuration conforme n’est pas la preuve qu’un tunnel l’a repris. La sortie d’état et une poignée de main neuve sont la preuve, et les collecter prend moins de temps que la réunion sur leur nécessité.