AES-GCM peut protéger la confidentialité d’un message et détecter les modifications non autorisées. À lui seul, il n’indique pas au destinataire si un message par ailleurs valide a déjà été traité.
Trois exigences sont faciles à confondre : des paires clé/nonce uniques pour le chiffrement, l’authentification du message et de son contexte, et la gestion du rejeu au niveau du protocole. HKDF peut aider à dériver les clés, mais ne satisfait pas automatiquement ces trois exigences.
La réutilisation d’un nonce et le rejeu sont des événements distincts
| Événement | Ce qui se passe | Protection requise |
|---|---|---|
| Réutilisation d’un nonce lors du chiffrement | Des textes en clair différents sont chiffrés avec la même clé GCM et le même nonce | Une stratégie fiable d’attribution des clés et des nonces |
| Altération | Le texte chiffré ou le contexte authentifié est modifié | Déchiffrement authentifié et rejet en cas d’échec |
| Rejeu | Un message chiffré auparavant valide est livré à nouveau | Un état et des règles applicatives reconnaissant les doublons ou les messages périmés |
| Réordonnancement | Des messages valides arrivent dans un ordre différent | Un ordre défini par le protocole et une gestion bornée des arrivées désordonnées |
Un texte chiffré rejoué peut toujours posséder une étiquette d’authentification valide. Rien n’a changé. Il est donc incorrect de dire que chaque doublon échoue automatiquement à l’authentification AES-GCM. La RFC 5116 sépare explicitement l’interface AEAD des services antirejeu.
Pourquoi la paire clé-nonce ne doit pas se répéter
Le nonce de GCM n’a pas besoin d’être secret, mais il doit respecter les exigences d’unicité du schéma pour une clé donnée. Un nonce de 96 bits, soit 12 octets, est courant ; choisir cette longueur ne garantit pas une génération correcte.
Réutiliser la même clé et le même nonce pour des textes en clair différents réutilise le flot de chiffrement et révèle des relations entre ces textes. Cela peut également compromettre l’authenticité et permettre des falsifications. Les conséquences sont graves, mais il ne faut pas les présenter comme la divulgation automatique de toutes les anciennes clés ou de tous les messages d’un compte. Le périmètre touché dépend de la clé réutilisée et du protocole.
La publication NIST SP 800-38D définit GCM et ses exigences. Les implémentations doivent respecter les limites d’invocation et les règles de génération des nonces applicables, plutôt qu’une règle simpliste du type « sûr jusqu’à tant de messages ».
Ce qu’apporte HKDF
HKDF, spécifié dans la RFC 5869, dérive du matériel de clé à partir de données secrètes d’entrée au moyen d’étapes d’extraction et d’expansion. Les protocoles peuvent utiliser des étiquettes de contexte et des entrées distinctes pour séparer les clés destinées à différents usages.
HKDF est déterministe. Si un client qui a planté ou a été ramené à un état antérieur répète le même état et les mêmes entrées, il peut dériver à nouveau la même sortie. Ajouter HKDF à une conception ne rend donc pas impossible la réutilisation des nonces.
Les clés par message peuvent réduire la quantité de contenu protégée par une même clé, mais la progression sûre de l’état, la séparation des clés et leur suppression restent importantes. Une même valeur de nonce sous des clés réellement différentes n’est pas la même défaillance que la répétition d’une paire clé/nonce ; le protocole doit établir que les clés sont effectivement différentes.
La protection contre le rejeu relève du protocole
Un destinataire peut suivre les identifiants de message, les positions de séquence, les époques de session ou les clés de ratchet consommées. Les champs pertinents doivent être authentifiés afin qu’un attaquant ne puisse pas réétiqueter un ancien message comme nouveau.
L’application doit ensuite décider ce que signifie un doublon. Afficher deux fois une bulle de conversation est gênant ; exécuter deux fois la même action peut être plus grave. Les nouvelles tentatives réseau sont normales, si bien qu’un traitement idempotent est souvent nécessaire en complément des contrôles cryptographiques.
N’exigez pas que tout message valide arrive strictement dans l’ordre, sauf si le protocole le prévoit. Les clients mobiles se reconnectent, réessaient et reçoivent couramment des messages retardés. Une gestion sûre distingue un message légitime en retard d’un message déjà consommé ou associé au mauvais contexte.
Que tester avant de revendiquer une protection
- Redémarrer après l’attribution d’un nonce mais avant l’enregistrement de l’envoi : l’attribution peut-elle se répéter ?
- Restaurer un ancien instantané de l’état : les clés, compteurs ou registres de rejeu peuvent-ils revenir en arrière ?
- Envoyer simultanément depuis deux processus de travail ou appareils : leurs domaines clé/nonce sont-ils séparés ?
- Livrer deux fois le même message valide : l’action applicative n’est-elle exécutée qu’une fois ?
- Modifier un identifiant de session ou un en-tête : le contexte est-il lié cryptographiquement ?
- Livrer des messages valides dans le désordre : les retards pris en charge sont-ils gérés sans accepter un état périmé ?
Les API de déchiffrement authentifié ne doivent restituer le texte en clair à l’application qu’après vérification réussie. C’est une exigence d’interface, et non l’affirmation qu’aucune implémentation ne calcule jamais de tampon temporaire de texte en clair en interne.
Lire précisément les affirmations de Livara
La documentation de sécurité de Livara mentionne AES-256-GCM, des chaînes par message et le contexte LVR1/LGS1. Ces primitives ne prouvent pas à elles seules une reprise correcte après plantage, une attribution correcte des nonces ou le rejet des rejeux. De telles affirmations nécessitent des détails de protocole versionnés et des preuves de test.
Une conception solide attribue explicitement chaque rôle : la dérivation produit les clés prévues, AEAD authentifie le contenu et le contexte, et la logique de protocole avec état décide si un message valide est acceptable maintenant.
