Résumé

  • RFC 3537 formait un enregistrement composé d’un octet de longueur, de la clé HMAC et d’un bourrage aléatoire afin de l’insérer dans un enveloppement 3DES ou AES.
  • Le désenveloppement retrouvait le bon nombre d’octets et vérifiait l’intégrité, sans lier l’algorithme HMAC, le rôle, le titulaire ni l’origine ; tout détenteur de la KEK pouvait produire une enveloppe acceptée.

Dans une salle d’archives, une pochette inviolée porte la mention « retirer vingt octets ». L’agent peut suivre cette instruction sans savoir à quel dossier rattacher la pièce ni quelle décision elle autorise. C’est cette différence entre mesure et mandat que RFC 3537 rendait visible dans la gestion d’une clé HMAC.

Publié en mai 2003 comme Proposed Standard, le document répondait à un défaut d’ajustement. L’enveloppement 3DES de RFC 3217 concernait des clés de chiffrement avec des contraintes de parité ; celui de RFC 3394 travaillait par blocs de 64 bits. Une clé HMAC pouvait avoir une autre longueur et aucune parité DES. RFC 3537 ajouta donc un enregistrement intérieur sans modifier les primitives sous-jacentes.

Cet enregistrement était LENGTH || KEY || PAD. LENGTH occupait un octet, KEY exactement le nombre d’octets indiqué, et PAD le minimum d’octets aléatoires nécessaire pour atteindre un multiple de huit. Le récepteur lisait la longueur, découpait la clé puis rejetait un reliquat de bourrage supérieur à sept octets.

L’expression « longueur arbitraire » libérait la clé des formats fixes, mais ne créait pas une représentation infinie. Le champ n’a qu’un octet. C’est une limite déduite de la structure, non une valeur maximale proclamée par le texte ; elle interdit néanmoins de transformer une commodité de l’introduction en promesse sans borne.

Dans la voie 3DES, un checksum de huit octets couvre longueur, clé et bourrage. Le résultat reçoit un IV aléatoire, est chiffré en CBC, préfixé par l’IV, renversé octet par octet, puis chiffré avec l’IV fixe 4adda22c79e82105. La voie AES confie l’enregistrement à RFC 3394 et n’interprète sa longueur qu’après le contrôle d’intégrité. Le registre A et les six passages restent le sujet de l’article RFC 3394 ; ici, l’objet est le contenu sémantiquement pauvre placé derrière cette porte.

L’enregistrement ne porte ni l’identifiant du HMAC futur, ni protocole, locataire, principal, identifiant de clé, date, expiration ou type de message permis. Le bourrage participe à l’intégrité, mais n’est pas une métadonnée de mission. LENGTH sait où la clé finit ; il ignore où l’autorisation finit.

Les deux OID ASN.1 de RFC 3537 nomment HMAC-with-3DES-wrap et HMAC-with-AES-wrap, avec un paramètre AlgorithmIdentifier obligatoirement NULL. Ils nomment la protection de l’enveloppe, pas l’algorithme HMAC consommateur. Déduire « HMAC-SHA-256 pour ce service » d’un OID d’enveloppement revient à ajouter une décision absente.

Les conseils de longueur restent eux aussi distincts. À partir de RFC 2104, le document recommande une clé au moins aussi longue que la sortie du hachage et rappelle qu’une longueur très supérieure au bloc n’apporte généralement rien. Or le désenveloppement ne choisit pas le hachage et n’applique aucun minimum propre à celui-ci. Une clé structurellement récupérée n’est pas automatiquement adéquate.

La section sécurité fixe la frontière d’origine : confidentialité et intégrité ne signifient pas nécessairement authentification de provenance. Toute personne possédant la KEK peut fabriquer une enveloppe qui passe le contrôle. Il faut authentifier la distribution de la KEK ou ajouter une signature. Le succès désigne un domaine de KEK, pas l’auteur à l’intérieur de ce domaine.

Une KEK compromise expose donc les anciennes clés et permet d’en introduire de nouvelles sous une forme valide. Lorsque plusieurs acteurs partagent la KEK, la confondre avec une identité agrandit silencieusement leur pouvoir. Conservation, destinataires et séparation des domaines doivent rester dans le dossier de preuve.

La fraîcheur aléatoire a une fonction limitée. La voie 3DES exige un nouvel IV à chaque invocation, même pour la même clé sous différentes KEK, et le bourrage est aléatoire. Il règle la forme cryptographique ; il ne devient ni identifiant HMAC ni nonce métier.

L’unique erratum Verified corrige le PAD du vecteur 3DES de 38be62 en be62fe. La nouvelle valeur correspond à l’enregistrement concaténé. Il s’agit d’une correction éditoriale, pas d’une révision de l’algorithme.

RFC 5652 décrit CMS, RFC 6031 des paquets de clés enrichis, RFC 4868 des identifiants HMAC-SHA-2, tandis que RFC 5649 et NIST SP 800-38F prolongent l’enveloppement avec bourrage. Ces cadres peuvent fournir le sens extérieur ; aucun ne l’insère rétroactivement dans LENGTH || KEY || PAD.

La chaîne de preuve doit donc conserver OID, KEK et droit d’appel, intégrité, longueur, octets, algorithme HMAC authentifié, identifiant, usage, principal, durée, exécution, vérification et résultat applicatif. RFC 3537 rendait la récupération interopérable. Il n’accordait pas à cette récupération le pouvoir de décider du reste.

Sources