Comment fonctionne un HMAC et pourquoi l'utiliser plutôt qu'un simple hachage ?
Réponse courte
Un HMAC est un code d'authentification de message à clé : il hache le message avec une clé secrète via une construction imbriquée (hachage interne et externe avec des bourrages dérivés de la clé). Il prouve à la fois l'intégrité (le message n'a pas été altéré) et l'authenticité (il vient de quelqu'un détenant la clé). Un simple hachage ne prouve ni l'un ni l'autre, puisque n'importe qui peut le recalculer ; HMAC résiste aussi aux attaques par extension de longueur.
Cette question vérifie si vous comprenez la différence entre intégrité (la donnée n'a pas été modifiée) et authenticité (la donnée provient d'une partie précise), et pourquoi un simple hachage ne vous offre ni l'une ni l'autre dans un contexte adversarial.
Pourquoi un simple hachage ne suffit pas
Si vous envoyez un message accompagné de SHA-256(message), un attaquant qui modifie le message peut simplement recalculer le hachage. Aucun secret n'est impliqué, donc le condensé ne prouve rien sur qui l'a produit. On pourrait penser que SHA-256(secret || message) corrige cela, mais c'est vulnérable à une attaque par extension de longueur : avec des hachages comme SHA-256 et SHA-1, connaître le condensé de secret || message permet à un attaquant de calculer un condensé valide pour secret || message || extra sans connaître le secret. Cela brise la sécurité recherchée.
Comment HMAC est construit
HMAC résout cela avec une construction imbriquée spécifique. Il dérive deux clés bourrées à partir du secret (un bourrage interne et un bourrage externe) et calcule :
HMAC = H( (clé ⊕ opad) || H( (clé ⊕ ipad) || message ) )
Le message est haché sous la clé, et ce résultat est haché à nouveau sous la clé. Ce double enveloppement est ce qui déjoue l'extension de longueur et lie le condensé au secret. Quiconque détient la clé peut vérifier l'étiquette ; quiconque ne la détient pas ne peut pas en forger une.
Ce que cela vous apporte
Un HMAC valide indique au destinataire deux choses à la fois : le message n'a pas été modifié et il a été produit par quelqu'un qui connaît la clé partagée. Il ne fournit pas de confidentialité — le message lui-même reste lisible sauf s'il est chiffré séparément, ce qui explique l'existence des modes de chiffrement authentifié.
Un piège d'implémentation
La comparaison de l'étiquette reçue avec celle calculée doit se faire à temps constant. Une comparaison naïve octet par octet qui s'arrête tôt fuit une information temporelle qu'un attaquant peut exploiter pour forger une étiquette.
Ce que recherchent les recruteurs
Mentionnez la clé secrète, la garantie intégrité-plus-authenticité, la résistance à l'extension de longueur comme raison de la conception imbriquée, et le détail de la comparaison à temps constant pour des points bonus.
Questions de suivi probables
- Pourquoi ajouter un secret à un message (hash(secret || message)) ne fonctionne-t-il pas de façon sûre ?
- Qu'est-ce qu'une attaque par extension de longueur et quels hachages y sont vulnérables ?
- Pourquoi la vérification d'un HMAC doit-elle utiliser une comparaison à temps constant ?