Résumé

  • RFC 3394 transforme n blocs de 64 bits en n+1 blocs chiffrés : le registre d’intégrité traverse six passages et devient le bloc de tête, plutôt qu’un remplissage ajouté après coup.
  • Le déballage ne restitue les données de clé que si le registre récupéré correspond à la valeur initiale attendue ; ce reçu ne prouve ni identité, ni autorisation, ni fraîcheur, ni bonne garde de la KEK.

Le détail le plus important de RFC 3394 était visible dans la longueur. Une entrée de n blocs ressortait sous la forme de n+1 blocs. Le supplément n’était pas une enveloppe inerte. Il portait l’état qui avait accompagné toutes les données, puis commandait leur sortie.

Publié en septembre 2002 comme RFC informatif, le texte transposait dans les archives de l’Internet l’algorithme AES Key Wrap de NIST. Il précisait que l’essentiel provenait de la spécification NIST et que les affirmations de sécurité relevaient du gouvernement américain, non d’une validation nouvelle par les auteurs. Son rôle était de rendre le calcul reproductible.

Les « données de clé » pouvaient contenir une clé, plusieurs clés ou des informations associées. La KEK acceptait les trois tailles AES, 128, 192 ou 256 bits. Les données étaient découpées en blocs de 64 bits, au moins deux. La sortie ajoutait exactement un bloc de même taille.

Les blocs entraient dans R[1] à R[n]. Un registre distinct A recevait une valeur initiale. Six tours parcouraient tout le tableau, soit 6n opérations AES. À chaque étape, A était concaténé avec un registre R; la moitié basse du résultat remplaçait R, et la moitié haute, combinée par XOR au compteur t, devenait le nouveau A.

Après le dernier tour, A devenait C[0], avant les registres de données transformés. Il avait rencontré chaque bloc et chaque position de compteur. Une altération, une mauvaise KEK, un ordre différent ou un autre contrat de valeur initiale devait donc empêcher le trajet inverse de retrouver le point de départ.

Le déballage inversait compteurs et opérations. Les octets reconstruits restaient candidats jusqu’au contrôle final. Si A retrouvé était une valeur initiale appropriée, les registres pouvaient être rendus. Sinon, l’implémentation devait produire une erreur et ne restituer aucune donnée de clé. Le contrôle n’était utile que s’il commandait réellement cette porte.

La valeur par défaut était A6 répété sur 64 bits. Le RFC associait sa récupération à une probabilité 2^-64 de données corrompues, sous les hypothèses cryptographiques du mécanisme. Ce nombre n’était ni une fréquence d’incident, ni une attribution du producteur, ni un certificat de sécurité du système environnant.

Le succès établit une cohérence étroite entre texte chiffré, KEK, variante et valeur initiale. Une KEK symétrique ne révèle pas quelle personne a produit le paquet. Le résultat ne prouve pas une autorisation, n’empêche pas à lui seul un rejeu, ne démontre pas que la KEK est restée secrète et ne garantit pas que la clé libérée conviendra à l’étape suivante.

Le RFC souligne justement le pouvoir extérieur au registre : compromettre la KEK peut révéler toutes les données qu’elle protège. Une KEK volée crée des enveloppes parfaitement acceptables. De même, réussir un vecteur d’essai ne prouve pas la résistance aux canaux auxiliaires, l’isolement, l’uniformité des erreurs ou la garde opérationnelle des secrets.

La limite de longueur était une partie du contrat. RFC 3394 exigeait au moins deux blocs et une longueur multiple de 64 bits. Il prévoyait cependant des valeurs initiales alternatives pour d’autres portées d’intégrité ou d’autres longueurs. Une implémentation générique devait donc savoir régler et tester cette valeur, pas seulement mémoriser une constante.

RFC 5649 a utilisé cette extension pour AES Key Wrap with Padding. Une valeur initiale alternative joint une constante de 32 bits à un indicateur de longueur de 32 bits. Le déballage vérifie constante, plausibilité de longueur et octets de remplissage nuls, avec un chemin spécial pour un seul bloc. Une prétention de longueur nouvelle a reçu un reçu nouveau.

Les identifiants ultérieurs — CMS dans RFC 3565, puis les familles AES-KW de JOSE et COSE — ont placé la transformation dans des protocoles précis. Ils guident le parseur vers une variante et une taille de KEK. Ils ne changent pas le registre en signature et ne confondent pas KW avec KWP.

Les errata vérifiés corrigent formulation et indices de tableaux ; les éléments conservés pour mise à jour précisent encore la notation et un lien mort. Ils montrent qu’une mécanique stable peut exiger une lecture éditoriale corrigée sans que ses six tours ou son seuil de restitution changent.

La spécification initiale minimale de Lu Heng éclaire le choix : fixer blocs, état, compteur, tours, valeur initiale et échec suffisait à l’interopérabilité. La garde, l’autorisation et l’usage restaient aux systèmes compétents. La primauté du code en fonctionnement impose ensuite de prouver que l’implémentation réelle retient bien les octets en cas d’échec et protège sa KEK.

Le registre supplémentaire séparait ainsi des octets plausibles d’une clé libérée. Son autorité était réelle et bornée. Il pouvait attester que l’enveloppe avait retrouvé la forme attendue, jamais dire qui méritait son contenu ni ce qui s’était passé après l’ouverture.

Sources