Résumé

  • RFC 2104 a enveloppé une fonction de hachage existante dans un passage intérieur puis un passage extérieur, séparés par deux constantes, sans imposer de modifier le code du hachage.
  • La fonction sous-jacente et la longueur du tag pouvaient varier ; l’algorithme, la clé, la représentation exacte du message et la règle de troncature faisaient donc partie de la preuve.
  • Un HMAC concordant n’établit pas, à lui seul, l’identité unique de l’émetteur, son autorisation, la fraîcheur, la canonicalisation, la confidentialité, la livraison ou la correction du système.

En 1997, le geste décisif ne consistait pas à inventer un hachage de plus. Les logiciels disposaient déjà de MD5, de SHA-1 et d’implémentations rapides. Le problème était de construire, à partir de ces briques, une authentification à clé secrète dont le principe soit analysable et dont l’intégration ne pousse pas chaque protocole à improviser.

RFC 2104 a fourni cette charnière. Sa réussite vient de la petitesse de son contrat : calculer un tag de manière commune, puis laisser les autres couches expliquer ce que ce résultat autorise réellement à conclure.

Deux domaines séparés autour du même hachage

Dans le RFC 2104, H désigne le hachage, B la taille de ses blocs et L celle de sa sortie. Une clé plus longue que B est d’abord hachée ; une clé plus courte est complétée jusqu’à B octets. Deux chaînes fixes introduisent ensuite une séparation : ipad répète 0x36 et opad répète 0x5c.

Le calcul est H((K xor opad) || H((K xor ipad) || text)). Le message entre dans le passage intérieur avec une première dérivation de la clé. Le résultat intérieur entre dans un passage extérieur avec une seconde dérivation. L’implémentation de H reste intacte.

Cette discipline répondait à plusieurs objectifs publiés : conserver les performances, simplifier la manipulation des clés, permettre une analyse cryptographique et remplacer facilement le hachage si nécessaire. Elle ne définissait ni le format métier du message, ni l’identité du détenteur de la clé, ni l’action à exécuter après validation.

L’optimisation ne rend pas les secrets inoffensifs

Le document permet de précalculer les états obtenus après les blocs intérieur et extérieur. Pour de petits messages, on économise ainsi deux opérations de compression répétitives. Ce choix local ne modifie pas l’interopérabilité.

Mais ces états doivent être protégés comme des clés. La remarque est essentielle : un dérivé réutilisable peut porter presque toute l’autorité opérationnelle du secret dont il provient. Enfermer le fichier de clé tout en exposant les états précalculés ne respecte que l’apparence du contrôle.

Le RFC exige aussi des clés aléatoires ou pseudo-aléatoires, une protection sérieuse, un échange sûr et un renouvellement périodique. La formule ne fournit aucune de ces pratiques. Elle rend possible une construction commune ; elle ne garantit pas la qualité de la matière secrète ni celle de son exploitation.

Le contexte donne sa portée au tag

Une application peut ne transmettre que les t bits de gauche du résultat. Cette troncature réduit la quantité à deviner et doit être définie par le protocole. Dire qu’un « HMAC est valide » sans nommer l’algorithme, la clé ou son époque, les octets authentifiés et la longueur du tag revient à conserver un verdict amputé de sa portée.

Les octets sont particulièrement importants. HMAC ne comprend pas que deux objets JSON ou deux chaînes Unicode représentent la même information. Une différence de tri, d’encodage ou d’espaces produit un autre tag. À l’inverse, deux parties peuvent authentifier avec succès une représentation incorrecte mais identique. La canonicalisation précède le MAC ; elle n’en émerge pas.

Une clé symétrique partagée limite également l’attribution. Tous ses détenteurs autorisés peuvent fabriquer un tag valide. La concordance indique qu’une personne ou une machine ayant accès à cette clé a pu authentifier ces octets. Elle ne choisit pas un acteur unique parmi eux et ne fournit pas la non-répudiation d’une signature numérique.

Les vecteurs ont fixé une frontière exécutable

En septembre 1997, le RFC 2202 a publié des cas d’essai HMAC-MD5 et HMAC-SHA-1. Des clés et messages connus associés à des sorties attendues ont permis à des implémentations indépendantes de comparer leur comportement au niveau exact des octets.

Réussir ces cas prouve une conformité ciblée. Cela ne couvre pas toutes les tailles, les erreurs, les comparaisons en temps constant, la sélection de clé en production, les limites de concurrence ou l’état anti-rejeu. Un bon test est d’autant plus utile que son résultat n’est pas confondu avec la sécurité entière du service.

L’agilité a survécu, mais la migration reste un travail

RFC 2104 citait MD5 et SHA-1 tout en gardant H abstrait. Plus tard, le RFC 4868 a spécifié HMAC-SHA-256, HMAC-SHA-384 et HMAC-SHA-512 pour IPsec. Le RFC 6151 a révisé l’appréciation de MD5 et indiqué que les nouveaux protocoles ne devaient pas employer HMAC-MD5.

L’interface avait donc prévu le remplacement, pas son exécution automatique. Il fallait encore ajouter des identifiants, négocier, déployer du code, tester les deux extrémités, modifier les politiques et faire tourner les clés. Une abstraction durable réduit la surface à changer ; elle ne supprime pas l’inertie institutionnelle.

La publication ultérieure de FIPS 198-1 par le NIST montre l’extension institutionnelle de HMAC. La longévité de la composition ne sanctifie pourtant aucun de ses premiers algorithmes.

La validation n’est qu’une étape du raisonnement

Un ancien message accompagné de son ancien tag peut encore vérifier. La fraîcheur exige un nonce, un compteur, une fenêtre temporelle ou un état équivalent. L’autorisation exige une règle reliant le contexte authentifié à une action permise. La confidentialité exige du chiffrement. La livraison et l’effet métier exigent leurs propres reçus. La sûreté de l’implémentation exige davantage que des vecteurs connus.

RFC 2104 a offert à l’Internet une pièce commune, stricte et mince. Deux passages ont rendu un MAC réutilisable. La décision de confiance devait toujours être construite autour de lui.

Sources