Attaques par rejeu et vulnérabilités liées à la réutilisation des nonces

Une valeur à usage unique garantit que le chiffrement deux fois du même message en clair produit des textes chiffrés différents. Cela est essentiel pour la sécurité sémantique : un attaquant qui observe plusieurs textes chiffrés n'apprend rien sur le fait qu'ils chiffrent des textes en clair identiques ou différents. Dans les chiffrements par flot et les chiffrements par blocs en mode CTR, la valeur à usage unique sert de graine à la génération du flot de clés, ce qui la rend essentielle à la sécurité.

Dans AES-GCM, la valeur à usage unique de 96 bits sert à initialiser un compteur pour le chiffrement en mode CTR et contribue également au calcul d'authentification GHASH. La valeur du compteur de chaque bloc AES est obtenue en incrémentant à partir de cette valeur à usage unique. Si deux chiffrements utilisent la même valeur à usage unique et la même clé, ils produisent le même flot de clés, de sorte que le XOR de leurs textes chiffrés est égal au XOR de leurs textes en clair.

Pour deux textes chiffrés GCM chiffrés avec la même paire (clé, valeur à usage unique), leur XOR est égal au XOR de leurs textes en clair. Si un attaquant connaît l'un des textes en clair, ce qui est fréquent dans les scénarios à texte en clair choisi, il récupère immédiatement l'autre. Même sans connaître de texte en clair, le XOR des textes chiffrés révèle des motifs linguistiques et peut être attaqué à l'aide de techniques de recherche guidée par des fragments probables. Il s'agit de l'un des modes d'utilisation abusive les plus catastrophiques de la cryptographie.

La réutilisation d'une valeur à usage unique dans GCM a une conséquence catastrophique supplémentaire, au-delà de la récupération du texte en clair. La clé d'authentification GHASH H est dérivée uniquement de la clé de chiffrement. Si deux messages partagent une même paire (clé, valeur à usage unique), l'attaquant peut résoudre des équations polynomiales pour récupérer H. Une fois H connu, l'attaquant peut contrefaire des balises d'authentification GCM valides pour des textes chiffrés arbitraires, ce qui compromet totalement l'intégrité des messages.

TLS 1.3 a tiré les leçons des risques de réutilisation des valeurs à usage unique observés dans les implémentations de TLS 1.2. TLS 1.3 génère les valeurs à usage unique de GCM en appliquant un XOR entre l'IV d'écriture de 12 octets, dérivé de la négociation, et le numéro de séquence de 8 octets, complété par des zéros jusqu'à 12 octets. Comme les numéros de séquence sont incrémentés pour chaque enregistrement, chaque enregistrement utilise une valeur à usage unique distincte. Cela élimine le risque lié à la génération aléatoire des valeurs à usage unique tout en garantissant leur unicité grâce au mécanisme des numéros de séquence.

Une attaque par rejeu capture un message valide ou un jeton d'authentification et le retransmet ultérieurement afin de produire un effet frauduleux. Exemples : rejouer une transaction bancaire pour facturer deux fois, rejouer une réponse d'authentification valide pour usurper l'identité d'un utilisateur ou rejouer une commande signée destinée à un appareil. L'attaquant n'a pas besoin de comprendre ou de modifier le message ; il lui suffit de retransmettre les données capturées pour réaliser l'attaque.

L'inclusion d'un horodatage dans les messages authentifiés assure une protection contre les attaques par rejeu. Le récepteur n'accepte les messages que dans une courte fenêtre temporelle, par exemple dans les 5 minutes suivant l'horodatage annoncé. Un message rejoué plusieurs heures plus tard se trouve en dehors de cette fenêtre et est rejeté. L'horodatage doit être authentifié, dans le HMAC ou dans les données supplémentaires d'AEAD, afin d'empêcher un attaquant de le modifier pour donner l'impression que le message est récent.

Les numéros de séquence offrent une protection contre les attaques par rejeu plus robuste que les horodatages, car ils détectent non seulement les replays anciens, mais aussi les livraisons en double ou dans le désordre. Le récepteur conserve le prochain numéro de séquence attendu ainsi qu'une fenêtre glissante des numéros récemment observés. Chaque message doit avoir un numéro de séquence situé dans la fenêtre acceptable et qui n'a pas déjà été observé. TLS utilise des numéros de séquence pour empêcher le rejeu d'enregistrements au sein d'une session.

Pour AES-GCM, la stratégie recommandée pour générer des valeurs à usage unique aléatoires consiste à utiliser 96 bits issus d'un générateur pseudo-aléatoire cryptographiquement sûr (CSPRNG). Avec des valeurs à usage unique aléatoires de 96 bits, la probabilité de collision liée à la borne des anniversaires atteint 2^-32 après 2^32 chiffrements, soit environ 4 milliards. Pour les applications à fort volume, passez à une valeur à usage unique fondée sur un compteur ou utilisez un autre mode AEAD, comme XChaCha20-Poly1305 avec sa valeur à usage unique de 192 bits, afin d'augmenter la limite sûre.

Les valeurs à usage unique déterministes fondées sur un compteur évitent les problèmes liés à la borne des anniversaires, mais nécessitent une gestion rigoureuse de l'état. Le compteur doit être conservé entre les redémarrages de l'application ; un compteur qui revient à zéro au redémarrage entraîne immédiatement la réutilisation d'une valeur à usage unique avec la même clé. Le compteur doit être mis à jour de manière atomique avant d'utiliser la valeur à usage unique, et non après. Dans les systèmes distribués, les valeurs à usage unique fondées sur un compteur nécessitent une coordination pour empêcher deux nœuds d'utiliser la même valeur de compteur.

XChaCha20-Poly1305 étend la valeur à usage unique de ChaCha20-Poly1305 de 96 à 192 bits. Avec des valeurs à usage unique aléatoires de 192 bits, la probabilité de collision liée à la borne des anniversaires est négligeable, même après 2^96 chiffrements, soit un nombre astronomique de messages. La génération aléatoire de valeurs à usage unique devient ainsi sûre sans préoccupation pratique liée aux anniversaires. Le crypto_secretbox de libsodium, basé sur XSalsa20-Poly1305, utilise des valeurs à usage unique de 192 bits pour la même raison.

Récapitulatif sur les valeurs à usage unique : elles garantissent l'unicité des textes chiffrés ; la réutilisation d'une valeur à usage unique dans GCM révèle le XOR des textes en clair et compromet l'authentification par la récupération de H ; TLS 1.3 utilise le XOR du numéro de séquence et de l'IV pour garantir l'unicité des valeurs à usage unique ; les attaques par rejeu retransmettent des messages valides sans les modifier ; les horodatages et les numéros de séquence dans les messages authentifiés empêchent le rejeu ; utilisez des valeurs à usage unique aléatoires de 96 bits pour GCM, en surveillant les bornes des anniversaires, ou XChaCha20 pour disposer d'un espace aléatoire plus vaste.