Un code d'authentification de message (MAC) est produit à partir d'un message et d'une clé secrète par un algorithme MAC. Une propriété importante d'un MAC est qu'il est impossible¹ de produire le MAC d'un message et d'une clé secrète sans connaître la clé secrète. Un MAC du même message produit par une clé différente semble sans rapport. Même connaître le MAC d’autres messages n’aide pas à calculer le MAC d’un nouveau message.

Un HMAC est un MAC basé sur une fonction de hachage. L'idée de base est de concaténer la clé et le message, et de les hacher ensemble. Puisqu'il est impossible, étant donné un hachage cryptographique, de savoir de quoi il s'agit, connaître le hachage (ou même une collection de tels hachages) ne permet pas de trouver la clé. L'idée de base ne fonctionne pas tout à fait, en partie à cause des attaques d'extension de longueur, donc la construction réelle du HMAC est un peu plus compliquée. Pour plus d'informations, parcourez la balise hmac sur Cryptography Stack Exchange, en particulier Pourquoi H (k || x) n'est-il pas une construction MAC sécurisée?, Est-ce que H ( k || length || x) une construction MAC sécurisée? et fonctions HMAC vs MAC. Il existe d'autres façons de définir un MAC, par exemple des algorithmes MAC basés sur des chiffrements par blocs tels que CMAC.

Un MAC authentifie un message. Si Alice voit un message et un MAC et connaît la clé secrète associée, elle peut vérifier que le MAC a été produit par un principal qui connaît la clé en effectuant elle-même le calcul MAC. Par conséquent, si un message est livré avec un MAC correct, cela signifie que ce message a été vu par un détenteur de la clé secrète à un moment donné. Un MAC est une signature basée sur une clé secrète, fournissant des assurances similaires à un schéma de signature basé sur une cryptographie à clé publique comme les schémas basés sur RSA où la signature doit avoir été produite par un mandant en possession de la clé privée.

Par exemple, supposons qu'Alice garde sa clé secrète pour elle-même et ne l'utilise que pour calculer les adresses MAC des messages qu'elle stocke sur un serveur cloud ou sur tout autre support de stockage non fiable. Si elle relit plus tard un message et voit un MAC correct qui y est attaché, elle sait que c'est l'un des messages qu'elle a stockés dans le passé.

Un HMAC en lui-même ne fournit pas l'intégrité du message. Il peut s'agir de l'un des composants d'un protocole garantissant l'intégrité. Par exemple, supposons qu'Alice stocke des versions successives de plusieurs fichiers sur un support non fiable, avec leurs MAC. (Encore une fois, nous supposons que seule Alice connaît la clé secrète.) Si elle relit un fichier avec un MAC correct, elle sait que ce qu'elle a relu est une version précédente d'un fichier qu'elle a stocké. Un attaquant contrôlant le support de stockage pourrait toujours renvoyer des versions antérieures du fichier ou un fichier différent. Une manière possible d'assurer l'intégrité du stockage dans ce scénario serait d'inclure le nom de fichier et un numéro de version dans le cadre des données dont le MAC est calculé; Alice aurait besoin de se souvenir du dernier numéro de version de chaque fichier afin de vérifier qu'elle ne reçoit pas de données périmées. Une autre façon d'assurer l'intégrité serait qu'Alice se souvienne du MAC de chaque fichier (mais alors un hachage ferait tout aussi bien dans ce scénario particulier).

¹ _{«Impossible» que d'exiger loin plus de puissance de calcul que possible.}

HMAC est une "signature" calculée souvent envoyée avec certaines données. Le HMAC est utilisé pour vérifier (authentifier) ​​que les données n'ont pas été modifiées ou remplacées. Voici une métaphore:

Vous allez envoyer un colis à Sarah qui contient une photo. Vous vous attendez à ce qu'elle ouvre le colis et regarde la photo. À un moment donné, dans un avenir proche, vous vous attendez à ce qu'elle vous renvoie le colis avec cette photo. Il est essentiel qu'elle remette la même photo dans l'emballage. Vous devez être absolument sûr qu'elle ne vous renvoie même pas une photo modifiée, ni la remplace par une autre. Vous avez des centaines de ces paquets sortis quotidiennement avec différentes photos; vous ne vous souviendrez jamais de la photo avec autant de détails que vous pourriez dire si elle en a changé un petit peu (comme si elle avait brossé un petit zit sur son visage).

Voici ce que vous pouvez faire: Avant de vous envoyez-lui le colis, placez une autre copie de la photo dans une petite boîte verrouillée. Gardez la clé. Placez la petite boîte verrouillée à l'intérieur du colis avec la photo originale que vous lui envoyez. Supposons qu'elle sache qu'elle ne doit pas retirer la boîte verrouillée du paquet. Lorsque vous recevez le colis d'elle, ouvrez-le, placez la photo sur la table. Ouvrez la boîte verrouillée, retirez la copie, comparez les deux. Si ce sont les mêmes, alors elle n'a pas modifié la photographie (elle est "authentique"). Si la boîte verrouillée n'est pas dans le paquet ou si votre clé ne l'ouvrira pas, alors supposez qu'elle a fait quelque chose de néfaste et jetez le paquet entier à la poubelle. La beauté ici est que vous n'avez pas besoin de "vous souvenir" de ce que vous lui avez envoyé à l'origine; tout ce dont vous avez besoin pour assurer la légitimité de la photo revient à l'intérieur du paquet.

Dans l'exemple ci-dessus, la petite boîte verrouillée représente un HMAC. Votre clé est la clé du HMAC. La photographie correspond aux données auxquelles vous appliquez le HMAC.

Ce qui précède est une métaphore aller-retour où vous seul avez une clé. Dans une situation différente, disons que vous envoyez souvent des colis à Tommy. Vous craignez que les facteurs curieux n'ouvrent vos colis et remplacent les photos ou les modifient. Vous faites la même chose avec la boîte verrouillée, sauf dans ce cas, vous laissez Tommy avoir une copie de la clé, de sorte que lorsqu'il reçoit un colis, il puisse ouvrir la boîte verrouillée incluse et comparer les photos lui-même. Si, à la réception, il trouve que les photos diffèrent, que sa clé n'ouvre pas la boîte, ou si la boîte manque, il sait que quelque chose est louche.

Les métaphores ci-dessus décrivent pourquoi les HMAC sont nécessaires, mais pas tellement comment ils travail. Changeons à nouveau la métaphore pour nous rapprocher de leur fonctionnement:

Conservons l'imagerie mentale du colis avec la photo: vous voulez l'envoyer par courrier, puis le recevoir à nouveau comme avant, en vous assurant que la photo était non modifié ou remplacé par le destinataire, ou pendant l'aller-retour.

Avant de fermer le colis et de l'envoyer, vous faites une copie de la photo. Pas de boîte verrouillée cette fois, au lieu de cela, vous passez la copie avec un mélange de produits chimiques liquides. Vous seul connaissez la recette (clé) de ce mélange, et chaque fois que vous passez le pinceau sur une copie, vous utilisez exactement les mêmes coups de pinceau. Le mélange tourbillonnera et brouillera la copie de la photographie en quelque chose qui ressemble à l'art moderne; appelons cela un HMAC. Vous ne savez pas exactement à quoi il ressemblera après séchage, mais vous savez que si vous brossez deux photos identiques avec la même recette et les mêmes coups de pinceau, les HMAC résultants auront la même apparence. Vous placez donc le HMAC séché dans l'emballage avec la photo originale et l'envoyez à Sarah.

Lorsque vous récupérez le package de Sarah, il contient ce que vous espérez être la photo originale non modifiée avec ce que vous attendez est le HMAC que vous avez créé et inclus avec elle. Sortez la photo de l'emballage, copiez-la et créez un autre HMAC avec cette copie (appliquez votre mélange / coups de pinceau). Comparez le HMAC que vous venez de créer avec le HMAC qui est revenu dans le package. S'ils sont identiques, vous pouvez être sûr que Sarah et les facteurs n'ont pas modifié la photo.

Si Sarah avait modifié la photo, alors les HMAC ne seront pas identiques.Si Sarah avait modifié le HMAC, alors les HMAC ne seront pas identiques.Si Sarah avait modifié la photo et essayé de créer un nouveau HMAC, alors les HMAC ne seront pas identiques (elle ne connaît pas votre recette).

Ainsi vous savez si la photo (les données) est authentique ou non, ce qui est exactement ce à quoi servent les HMAC.

La réponse courte est "HMAC fournit des signatures numériques en utilisant des clés symétriques au lieu de PKI". Essentiellement, si vous ne voulez pas faire face à la complexité des clés publiques / privées, de la racine de confiance et des chaînes de certificats, vous pouvez toujours avoir une signature numérique fiable avec HMAC. HMAC repose sur une cryptographie à clé symétrique et des secrets pré-partagés au lieu de paires privées / publiques. L'inconvénient est le même que pour la cryptographie à clé symétrique en général - vous devez maintenant vous soucier de la distribution et de la protection de vos clés secrètes.

1. Vous utilisez HMAC chaque fois que vous souhaitez que l'intégrité des données soit préservée (et l'authenticité)

2. La clé fait partie du HMAC, car il s'agit d'un secret partagé connu entre 2 parties uniquement et elles seules peuvent créer le HMAC et personne d'autre. (Garantit l'authenticité

3. Les attaques par extension de longueur ne sont pas possibles sur HMAC. Les MAC, quant à eux, ajoutent simplement la clé au message, qui y est sensible. HMAC a été introduit pour surmonter cette attaque sur les MAC.

• Les HMACS sont utilisés lorsque vous devez vérifier deux "intégrité" et "authenticité". Par exemple: considérez un scénario dans lequel on vous envoie un élément de données avec son hachage - vous pouvez vérifier l'intégrité du message en recalculant le hachage du message et en le comparant avec le hachage que vous avez reçu. Cependant, vous ne savez pas avec certitude si le message et le hachage ont été envoyés par quelqu'un que vous connaissez / en qui vous avez confiance. Si vous aviez recours au HMACS, vous pourriez recalculer le HMAC en utilisant une clé secrète que seuls vous et une partie de confiance connaissez, et le comparer avec le HMAC que vous venez de recevoir - en fait, dans le but d '«authenticité».

• Comme je l'ai mentionné précédemment, le secret de la clé garantit que le HMAC a été calculé par une partie de confiance.

• Les HMACS ne sont pas hachages à clé. Les attaques d'extension de longueur sont possibles lorsque vous utilisez des hachages par clé, et non HMACS. Pour en savoir plus, consultez ceci.

[EDIT]

Réponse modifiée pour répondre au commentaire ci-dessous: - "Je ne comprends toujours pas pourquoi la clé est dans le message? Est-ce que je ne connais pas la clé publique du correspondant? Si je connais la clé publique alors pourquoi la clé dans le message utilise-t-elle plutôt la clé déjà connue? Si Je ne connais pas la clé alors pourquoi devrais-je faire confiance à cette partie? "

• La clé n'est pas" dans "le message. La clé est utilisée pour générer le HMAC à partir d'un message. La clé utilisée pour générer HMACS n'est pas une "clé publique" quelconque. C'est plus comme un secret partagé entre deux parties. Vous pouvez consulter la méthode d'authentification de l'API REST pour les éléments AWS afin de mieux comprendre comment HMACS est utilisé pour la signature d'URL.