Résumé

  • Une enveloppe CMS peut porter le bon identifiant AES-GCM, des paramètres conformes et un tag valide sans apporter la preuve historique qu’aucun couple clé/nonce identique n’existe ailleurs.
  • La RFC 5084 impose donc une gestion automatisée des clés et présente une clé de chiffrement de contenu neuve pour chaque contenu comme construction sûre ; le nom de l’algorithme ne remplace pas cette discipline.

Deux enveloppes arrivent aux archives à plusieurs mois d’intervalle. Chacune se décode proprement. Leur identifiant désigne AES-GCM, leur nonce mesure douze octets et leur tag est accepté. Examinées séparément, elles semblent irréprochables. La question décisive ne se trouve pourtant dans aucune des deux : ont-elles utilisé la même clé ?

La RFC 5084 fournit à CMS les conventions d’emploi d’AES-CCM et d’AES-GCM dans AuthEnvelopedData. Elle ne se contente pas de citer deux modes. Elle situe l’identifiant d’algorithme, définit les OID correspondant aux trois tailles de clé AES, rend les paramètres obligatoires et relie les attributs authentifiés aux données associées authentifiées, ou AAD.

Pour GCM comme pour CCM, la règle porte sur l’ensemble des opérations réalisées sous une même clé. Un nonce ne doit jamais s’y répéter. Réemployer le couple clé/nonce pour deux messages différents détruit les propriétés de sécurité. L’objet courant montre son nonce ; il ne contient ni l’inventaire des envois précédents, ni l’état d’un autre émetteur, ni l’historique perdu lors d’une restauration.

La preuve est donc relationnelle. La conformité locale de l’enveloppe se vérifie avec ses octets, la clé et les AAD. L’unicité exige de rapprocher l’opération de toutes celles qui partagent réellement la même clé. Un journal limité à un serveur ne suffit pas si la clé couvre une région. Un contrôle régional ne suffit pas si elle couvre plusieurs régions.

La RFC en tire une obligation opérationnelle nette : les implémentations doivent employer un système automatisé de gestion des clés. Elle décrit le transport de clé, l’accord de clé, les clés symétriques de chiffrement de clés et les clés dérivées d’un mot de passe. Ces quatre voies satisfont l’exigence lorsqu’une clé de chiffrement authentifié du contenu, la CEK, est créée à neuf pour chaque contenu.

Cette stratégie réduit la coordination. Deux objets peuvent alors porter les mêmes octets de nonce sans répéter le couple interdit, puisque leurs CEK diffèrent. À l’inverse, une CEK durable reste possible à condition de posséder un allocateur de nonces atomique, durable et commun à toute sa portée. Ni l’OID ni le tag ne prouvent l’existence de cet allocateur.

Les paramètres gardent une autorité précise. GCMParameters transporte le nonce et une longueur d’ICV comprise entre douze et seize octets ; douze octets sont recommandés et constituent la valeur par défaut. La longueur déclarée doit correspondre au champ mac. Pour CCM, le nonce compte de sept à treize octets et la longueur d’ICV appartient à la série paire de quatre à seize octets, douze étant recommandés. La RFC explique aussi l’arbitrage entre taille du nonce CCM et capacité d’encodage de la longueur du contenu.

Ces contrôles permettent de refuser un paramètre absent, une longueur impossible ou un décalage avec le MAC. Ils ne disent pas que le générateur de clés disposait d’une entropie suffisante, que la politique locale accepte le tag choisi, ni que la machine clonée n’a pas repris le compteur de sa source.

La surface protégée demande la même rigueur. La RFC 5083 définit AuthEnvelopedData. Dans la RFC 5084, les attributs authentifiés en forment les AAD : ils sont protégés mais restent lisibles. Le contenu chiffré et ces attributs sont couverts par le MAC. Un attribut non authentifié voyage dans le conteneur sans acquérir pour autant une valeur d’autorisation.

Une application qui transforme un tel attribut en ordre métier franchit une autre frontière. La validation du tag prouve une correspondance cryptographique entre les entrées protégées et la clé utilisée. Elle ne prouve ni l'identité humaine, ni la légitimité du document, ni le droit du destinataire à déclencher une opération après déchiffrement.

La RFC 5116 généralise l’interface AEAD, tandis que la recommandation NIST SP 800-38D souligne le caractère critique de l’unicité de l’IV pour GCM. Dans les deux cas, l’algorithme traite l’entrée qu’on lui fournit. Il ne peut pas retrouver un doublon caché dans une sauvegarde ancienne.

Une preuve exploitable doit donc référencer la clé sans la divulguer. Pour chaque objet, il faut pouvoir associer un identifiant non secret d’époque de clé, la portée de l’allocateur, l’événement d’attribution du nonce, l’encodage exact des attributs authentifiés, le condensat du texte chiffré, la longueur du tag, le résultat de vérification et la version logicielle.

Le scénario de reprise montre le risque. Un site primaire chiffre avec le compteur 8 004. La réplication de l’état s’arrête à 8 003. Le site secondaire prend la main, conserve la même CEK et émet un autre contenu avec 8 004. Les deux pièces peuvent rester individuellement valides. Seule la réunion par la véritable époque de clé révèle la faute.

L’erreur inverse coûte aussi cher. Deux CEK neuves emploient par hasard le même nonce. Un détecteur qui ne connaît pas l’identité de clé déclenche une alerte injustifiée. Le registre doit donc être assez large pour trouver le doublon réel, et assez précis pour ne pas en inventer.

Une chaîne de preuve raisonnable conserve séparément : les octets CMS ; l’OID et les paramètres décodés ; l’époque non secrète de CEK ou la preuve de création d’une CEK neuve ; l’attribution atomique du nonce ; les AAD exactes ; le condensat du chiffré et la longueur du tag ; la branche de gestion de clé et le destinataire ; les résultats de décodage, de déballage et de vérification ; la recherche de doublon à la bonne portée ; la libération du texte clair ; enfin l’autorisation et le résultat applicatifs.

Il s’agit d’une recommandation d’exploitation, non d’une syntaxe ajoutée à la RFC 5084. Dans la discipline des couches de réalité de Heng Lu, l’identifiant d’algorithme, l’objet encodé, le tag vérifié, l’unicité historique et la décision métier sont des pièces voisines. Aucune ne reçoit automatiquement l’autorité de la suivante.

Sources