Ce qu’est un nonce dans un VPN et pourquoi le réutiliser casse le tunnel

La plupart des gens rencontrent le mot nonce dans un profil VPN et supposent qu’il s’agit d’un autre secret partagé à copier entre pairs. Ce n’est pas le cas. Un nonce est une valeur qui ne doit jamais se répéter sous la même clé, et dans la plupart des chiffrements fondés sur un nonce, il circule en clair. La confusion reste inoffensive jusqu’à ce que quelqu’un le modifie à la main, et c’est là que la vraie casse commence.

D’où vient réellement le nonce

Le chiffrement authentifié a besoin d’un nonce différent pour chaque message chiffré sous une clé. Les protocoles satisfont cette exigence de diverses manières : un compteur qui croît de façon monotone, un sel combiné à un identifiant de paquet ou une valeur aléatoire suffisamment longue. IKEv2 échange des nonces lors de l’échange initial, et ce sont des entrées publiques pour la dérivation de clé, non des secrets.

L’unicité peut être structurelle ou probabiliste. Un compteur ne peut pas se répéter avant de boucler, c’est pourquoi le protocole définit un point de renouvellement de clé bien avant. Une valeur aléatoire repose sur assez de bits pour qu’une collision soit invraisemblable dans la limite de messages, ce qui est un argument différent avec un mode de défaillance différent. La documentation du protocole indique quelle méthode s’applique, et les deux ne sont sûres que tant que la limite annoncée est respectée.

Ce que coûte réellement la réutilisation

Réutiliser un nonce sous une clé n’est pas une question mineure d’efficacité. Avec GCM, deux messages partageant un IV permettent à un observateur de récupérer la clé d’authentification et de calculer le ou exclusif des deux textes en clair. Les constructions fondées sur un flux réutilisent le flux de clé de la même manière, ce qui transforme le texte chiffré en énigme plutôt qu’en secret.

C’est pourquoi les implémentations renouvellent la clé avant qu’un compteur ne boucle, et pourquoi elles s’arrêtent au lieu de continuer lorsque leur état est incertain. Un redémarrage qui réinitialise un compteur alors que le pair détient encore l’ancienne clé, ou une machine virtuelle restaurée depuis un instantané pris en milieu de session, est exactement la situation que les limites existent pour empêcher. Aucun attaquant n’est nécessaire ; les opérations ordinaires suffisent.

Pourquoi l’édition manuelle est la mauvaise solution

Les compteurs, les sels et les identifiants de paquet sont des machines d’état partagées par les deux extrémités. Modifier un côté désynchronise l’autre, et le tunnel échoue d’une manière qui ressemble à un problème de routage. Le levier pris en charge est un nouvel échange de clés, qui réinitialise l’état des deux côtés à la fois.

Les mots de passe et les nonces jouent aussi des rôles différents. Un mot de passe est une entrée secrète pour la dérivation de clé ; un nonce est une entrée publique par message. Un champ de profil étiqueté nonce qui demande un long secret est généralement une clé statique ou un secret prépartagé sous un autre nom, alors lisez la documentation de ce champ au lieu de supposer.

Quand un avis concerne la gestion des nonces, la réparation est la version corrigée du mainteneur, pas un autre chiffrement ni une clé plus courte. Changer le chiffrement pour éviter le mot nonce déplace le problème au lieu de le résoudre.

Lire un avertissement sans deviner

Une ligne de journal sur des compteurs ou des nonces décrit généralement un état perdu plutôt qu’une attaque. Vérifiez si un pair a redémarré, si une machine virtuelle clonée a réutilisé la même identité et si les deux extrémités s’accordent sur les réglages de renouvellement de clé. Établissez ensuite une nouvelle session et regardez si le message revient.

Gardez le diagnostic séparé des défaillances sans rapport. Une page qui ne se charge pas, ou une invite d’identifiants qui boucle, n’est pas une preuve de réutilisation de nonce, et la traiter comme telle vous envoie dans la couche cryptographique alors que le problème est au-dessus.

Pour un usage ordinaire, la règle sûre est courte : laissez l’implémentation gérer le nonce, maintenez les deux extrémités sur des versions prises en charge et traitez toute réinitialisation d’état comme une raison de renouveler la clé plutôt que de modifier une valeur. Si un champ de profil ne figure pas dans la documentation du fournisseur, n’inventez pas de valeur pour lui. Réparer le tunnel commence par savoir quelle couche vous regardez.