Hash HMAC

Un HMAC (Hash-based Message Authentication Code) est un code d'authentification calculé à partir d'un message, d'une clé secrète partagée et d'une fonction de hachage cryptographique, comme SHA-256. Il permet de vérifier l'intégrité du message et son authenticité au regard de la clé partagée. Contrairement à un haché classique, il nécessite une clé secrète pour produire un tag valide.

Un hash (haché), comme SHA-256, produit une empreinte du message sans utiliser de clé secrète. Un HMAC utilise en plus une clé secrète partagée pour authentifier le message.

Un haché seul ne protège pas contre la falsification si un attaquant peut modifier simultanément le message et son empreinte.

Un HMAC valide permet de vérifier l'intégrité du message et sa compatibilité avec la clé secrète.

Les HMAC servent notamment à authentifier des données et des requêtes :

— Webhooks : GitHub utilise HMAC-SHA256 dans l'en-tête X-Hub-Signature-256 ; Stripe utilise notamment HMAC-SHA256 dans Stripe-Signature.

— Jetons : les JWT utilisant HS256 sont signés avec HMAC-SHA256.

— Cookies et sessions : vérifier que les données signées n'ont pas été modifiées, sans les chiffrer.

— API : AWS Signature Version 4 utilise HMAC-SHA256 pour signer les requêtes et dériver des clés.

— Dérivation de clés : PBKDF2 peut utiliser HMAC comme fonction pseudo-aléatoire interne.

Les variantes courantes sont :

— SHA256 : tag complet de 256 bits (32 octets), choix courant pour les nouvelles applications.

— SHA512 : tag de 512 bits (64 octets).

— SHA384 : tag de 384 bits (48 octets).

— SHA1 : encore présent dans des systèmes anciens, mais à éviter dans les nouvelles applications.

— HMAC-MD5 : déconseillé pour les nouvelles applications, même si les collisions connues de MD5 ne cassent pas directement HMAC-MD5.

La construction HMAC définie par la RFC 2104 repose sur deux hachages imbriqués :

$$ HMAC(K,M)=H((K' \oplus opad) \parallel H((K' \oplus ipad) \parallel M)) $$

— $ K $ : clé secrète ; $ K' $ : clé normalisée selon la taille de bloc de la fonction de hachage.

— $ M $ : message à authentifier.

— $ H $ : fonction de hachage.

— $ \oplus $ : XOR (OU exclusif) ; $ \parallel $ : concaténation.

— $ ipad $ et $ opad $ : blocs d'octets constants utilisés respectivement dans le hachage interne et externe.

En pratique, privilégier une bibliothèque cryptographique plutôt qu'une implémentation manuelle.

Le résultat comporte 64 caractères hexadécimaux pour HMAC-SHA256. Dans une application réelle, utiliser une clé secrète aléatoire et sécurisée. Le message doit être identique octet par octet lors du calcul et de la vérification.

Un HMAC n'est pas un chiffrement : son tag ne contient pas le message original sous une forme récupérable.

Retrouver le message ou la clé nécessiterait notamment de tester des candidats.

Une clé aléatoire de 256 bits est hors de portée d'une recherche exhaustive réaliste.

Une clé issue d'un mot de passe faible reste vulnérable aux attaques par dictionnaire.

Recalculer le HMAC avec la même clé, le même message et les mêmes paramètres, puis comparer les tags.

Informatiquement préférer une fonction de comparaison à temps constant.

— Longueur : HMAC-SHA256 complet produit 32 octets (64 caractères hexadécimaux) ; HMAC-SHA512, 64 octets ; HMAC-SHA1, 20 octets ; HMAC-MD5, 16 octets.

— Format : GitHub utilise le préfixe 'sha256=' ; Stripe utilise notamment t= et v1= dans Stripe-Signature ; AWS Signature Version 4 emploie des champs comme Signature et SignedHeaders.

— Contexte : en-tête HTTP, paramètre d'API ou champ nommé hmac.

Privilégier les bibliothèques cryptographiques standard :

— Python : hmac et hashlib.

— Node.js : crypto.createHmac().

— Java : javax.crypto.Mac.

— PHP : hash_hmac().

— Rust : crates hmac et sha2.

— OpenSSL : commande openssl dgst avec l'option -hmac.

Toute personne disposant de la clé peut produire des HMAC valides et falsifier les messages concernés.

La clé doit donc rester confidentielle.

Après une fuite, révoquer la clé compromise.

Une collision survient lorsque deux entrées différentes produisent le même hash. Les collisions connues contre MD5 et SHA-1 ne permettent pas, à elles seules, de falsifier directement un HMAC sans connaître la clé.

La sécurité de HMAC ne dépend toutefois pas uniquement de la résistance aux collisions.

HMAC présente plusieurs limites :

— Gestion des clés : l'émetteur et le vérificateur doivent partager un secret.

— Non-répudiation : plusieurs détenteurs de la clé pouvant produire un tag valide, HMAC ne permet pas de prouver lequel a signé le message.

— Rejeu : un message authentique peut être retransmis. Un timestamp ou un nonce, accompagné de contrôles adaptés, permet de limiter ce risque.

— Confidentialité : HMAC ne chiffre pas le message.

— Sérialisation : toute différence dans la représentation des données peut invalider le tag.