MAC-puis-chiffrer dans le protocole SIGMA pour l'échange de clés authentifiées
Le protocole SIGMA proposé en 2003 et utilisé dans TLS 1.3 et IKE signifie «SIGn-and-MAc» et peut éventuellement protéger l'identité à l'aide du cryptage.
La variante SIGMA-I illustrée ci-dessous indique qu'elle utilise une approche MAC-then-encrypt:
Ici $\{\dots \}_{K} $ désigne le cryptage des informations entre les crochets sous une fonction de cryptage symétrique utilisant la clé $K$.
Existe-t-il une raison particulière d'utiliser MAC-puis-crypter plutôt que crypter-puis-MAC pour les protocoles d'échange de clés? Je n'ai pas été en mesure de trouver une meilleure réponse qu'il ne semble arbitraire en regardant une comparaison entre MAC-puis-crypter et crypter-puis-MAC .
Edit: RFC 7366 lié dans cette réponse connexe donne quelques indices que crypter-puis-MAC devrait être préféré (D) Communication TLS (aucun n'est dit sur l'établissement de liaison). En particulier, il déclare:
TLS et DTLS utilisent une construction MAC-then-encrypt qui était considérée comme sécurisée au moment où le protocole Secure Socket Layer (SSL) original a été spécifié au milieu des années 1990, mais qui n'est plus considérée comme sécurisée.
Fait intéressant, H Krawczyk (l'auteur de SIGMA) a écrit en 2001 l'Ordre du chiffrement et de l'authentification pour la protection des communications (ou: Quelle est la sécurité du SSL?) - avant SIGMA.
Réponses
Arnaud m'a demandé de clarifier cette question.
Il est vrai que l'on devrait utiliser un mode de cryptage authentifié ou crypter-puis-MAC, et le journal le dit explicitement. En effet, le texte explicatif de l'article suivant la figure ci-dessus (section 5.2 dehttps://webee.technion.ac.il/~hugo/sigma-pdf.pdf) résout ce problème. Ça dit:
Nous soulignons que la fonction de cryptage (telle qu'appliquée dans le troisième message) doit être résistante aux attaques actives et doit donc combiner une certaine forme de protection de l'intégrité. Des transformées combinées secret-intégrité telles que celles de [16] peuvent être utilisées, ou un mode conventionnel de cryptage (par exemple CBC) peut être utilisé avec une fonction MAC calculée au-dessus du texte chiffré [3, 26].
À savoir, le cryptage noté $\{...\}_{K_e}$doit utiliser un schéma de chiffrement authentifié. (La nécessité d'un cryptage authentifié est également répétée dans l'annexe B qui montre un protocole plus complet sous la forme de SIGMA-R).
Le fait qu'il y ait un MAC (sur l'identité) sous le cryptage est simplement parce que le MAC est (une partie essentielle) du protocole SIGMA et est totalement indépendant du cryptage (en particulier, nécessaire même si vous ne vous souciez pas de la protection des identités ). Ainsi, bien que cela ressemble à "MAC-then encrypt", il n'a aucun rapport avec ce mode de cryptage.
Remarque: La raison pour laquelle le texte indique que le cryptage authentifié n'est nécessaire que pour le troisième message est que, comme indiqué au début de ce même paragraphe, SIGMA-I protège l'identité de l'initiateur des attaquants actifs et l'identité du répondeur des les attaquants. Ainsi, le chiffrement de l'identité du répondeur n'a besoin que d'une sécurité contre les attaques passives pour lesquelles un chiffrement UNauthenticated suffit. C'est vraiment une remarque académique puisque dans la pratique on utiliserait le même schéma de cryptage pour les deux flux, à savoir un cryptage authentifié pour les deux.
C'est un peu une spéculation, mais je suppose que cela est dû à la manière modulaire dont Sigma a été conçu. À savoir, lorsque Hugo Krawczyk a conçu Sigma, la principale propriété de sécurité qu'il recherchait était la sécurité AKE qui se compose essentiellement de deux choses:
Indiscernabilité des clés de session: l'adversaire ne devrait pas être capable de distinguer les clés de session réelles des clés aléatoires; et
Authentification d'entité explicite (EA): propriété selon laquelle, une fois qu'un participant au protocole a terminé l'exécution du protocole, il est garanti qu'il communiquait en fait avec la partie attendue et que cette partie a bien calculé la même clé de session.
La propriété EA est essentiellement une étape de confirmation clé qui assure la vivacité et l'authentification. Ceci est réalisé en calculant un MAC sur certaines des données du protocole, à l'aide d'une clé$K_m$ dérivé du même secret principal utilisé pour dériver la clé de session.
Le fait est que vous pouvez obtenir la sécurité AKE (c'est-à-dire les propriétés 1 et 2) sans aucun cryptage! En effet, lorsque Krawczyk prouve que Sigma satisfait à la sécurité AKE (je ne me souviens plus de quel papier il s'agissait; essaiera de le retrouver plus tard), il suppose simplement que l'étape de cryptage n'est pas du tout là! (Il le fait également dans son article OPTLS, qui est le précurseur de TLSv1.3).
Comme je l'ai dit, l'objectif de sécurité standard pour la plupart des protocoles d'échange de clés, depuis les articles originaux de Bellare et Rogaway , concernait essentiellement la sécurité AKE. Cependant, lorsque Krawczyk a conçu Sigma, il a également voulu ajouter une autre fonctionnalité non standard, à savoir la protection de l'identité . Mais étant donné qu'il avait déjà montré que le protocole Sigma sans cryptage atteignait la sécurité AKE, il s'agissait simplement d'ajouter un cryptage en plus de cela afin d'obtenir également une protection d'identité. Ainsi: MAC-puis-Crypter.
Mais notez que ces deux utilisations du MACing et du cryptage sont plutôt orthogonales et servent des objectifs différents: le MAC interne est censé fournir la sécurité EA, tandis que le cryptage externe est censé fournir une protection d'identité.
En outre, notez que Sigma généralement n'utilise Crypter-then-MAC. En particulier, lors de l'instanciation de Sigma dans IKEv2 , le cryptage externe est accompagné d'un MAC supplémentaire en dehors du cryptage à la manière EtM standard. Dans IKEv2, la clé MAC interne est appelée , la clé de cryptage externe est appelée et la clé MAC externe est appelée (le est soit ou selon que ce message est créé par l'initiateur ou le répondeur). De plus, dans les instanciations plus récentes d'IKEv2, le cryptage externe est remplacé par des algorithmes de cryptage authentifiés dédiés. Dans ce cas, les clés ne sont pas utilisées (et toute la question EtM devient sans objet). Dans l'instanciation TLSv1.3 de Sigma, seul le cryptage authentifié est utilisé. Mais encore une fois, notez qu'à l' intérieur du cryptage (que ce soit AE ou EtM), il y a un MAC interne dont le but est de fournir la sécurité EA.SK_p*SK_e*SK_a**irSK_a*