À quoi servent les données authentifiées associées dans l'AEAD?
Le cryptage authentifié (AE) et le cryptage authentifié avec les données associées (AEAD, variante de AE) est une forme de cryptage qui fournit simultanément des garanties de confidentialité, d'intégrité et d'authenticité sur les données.
Source : Wikipedia
J'ai récemment remarqué que plusieurs vérificateurs SSL ont commencé à signaler AEAD. Mais, quelle est la différence entre AE et AEAD et quel est le but des "données authentifiées associées" à une connexion cryptée? Pourquoi ne pas tout chiffrer, au lieu de "l'authentifier" uniquement?
En règle générale, le but des données associées (ci-après "AD") est de lier un texte chiffré au contexte où il est censé apparaître, de sorte que les tentatives de "couper-coller" un texte chiffré valide dans un contexte différent puissent être détecté et rejeté.
Par exemple, supposons que je crypte les valeurs que j'insère dans une base de données clé/valeur et que j'utilise la clé d'enregistrement comme AD. Qu'est-ce que ça fait? Eh bien, tout d'abord, mécaniquement, cela signifie maintenant que chaque fois que je déchiffre la valeur, je dois présenter la même clé que AD, sinon le déchiffrement échouera avec une erreur d'authenticité. Mon application devra donc effectuer cette étape afin de décrypter correctement les données.
Deuxièmement, et plus profondément, en utilisant la clé comme AD, j'ai déjoué une sorte d'attaque qu'un initié - par exemple, l'administrateur de la base de données - pourrait imaginer mener contre mon application: prendre deux enregistrements dans la base de données et échanger leurs valeurs . Sans l'AD, l'application les décrypterait volontiers et supposerait aveuglément qu'elle a lu la valeur correcte pour ces clés. Avec la clé comme AD, l'application remarquerait immédiatement que les valeurs ne sont pas authentiques, même si l'attaquant ne les a jamais réellement modifiées, car elles se produisent dans le mauvais contexte. Ce n'est qu'un exemple parmi tant d'autres possibles, mais les applications de données associées ont généralement cette saveur.
Un détail important que les gens oublient souvent dans les exemples est que les données associées ne doivent pas nécessairement être stockées ou transmises avec le texte chiffré. Toutes les valeurs non secrètes dépendantes du contexte que les parties honnêtes sont capables de déduire correctement peuvent être utiles en tant que données associées. Par exemple, si les parties exécutent un protocole complexe qui a été formulé en termes de machine d'État, de telle sorte que chaque partie correcte puisse toujours dire son propre état et celui dans lequel une contrepartie honnête devrait se trouver, alors ces États, même s'ils '' re implicite au protocole - peut être utilisé comme AD. C'est le genre de choses qui rendent les suites AEAD si attrayantes pour les concepteurs de protocoles comme TLS - c'est un outil qui peut être utilisé pour réduire la complexité d'un protocole sécurisé.
De RFC 5116 - Une interface et des algorithmes pour le chiffrement authentifié :
Cryptage authentifié BN00 est une forme de chiffrement qui, en plus d'assurer la confidentialité du texte en clair chiffré, permet de vérifier son intégrité et son authenticité.
Chiffrement authentifié avec données associées ou AEAD R02 , ajoute la possibilité de vérifier l'intégrité et l'authenticité de certaines données associées (AD) , également appelées "données authentifiées supplémentaires", ce qui n'est pas crypté.
Et de 2.1 - Authenticated Encryption:
Les données associées A sont utilisées pour protéger les informations qui doivent être authentifiées, mais n'ont pas besoin d'être gardées confidentielles. Lorsque vous utilisez un AEAD pour sécuriser un protocole réseau, par exemple, cette entrée peut inclure
- adresses,
- ports,
- numéros de séquence,
- numéros de version du protocole,
- et d'autres champs qui indiquent comment le texte en clair ou le texte chiffré doit être traité
- transmis
- ou traitées.
Dans de nombreuses situations, il est souhaitable d'authentifier ces champs, bien qu'ils doivent être laissés en clair pour permettre au réseau ou au système de fonctionner correctement. Lorsque ces données sont incluses dans l'entrée A, l'authentification est fournie sans copier les données dans le texte en clair.
En 2002, Phillip Rogaway a noté:
Chiffrement authentifié avec données associées
Oʀɪɢɪɴ ᴏꜰ ᴛʜᴇ ᴘʀᴏʙʟᴇᴍ. La nécessité de traiter les données associées lors de l'utilisation d'un mode AE intégré a d'abord été signalée à l'auteur par Burt Kaliski [16]. Plusieurs autres personnes ont rapidement communiqué le même sentiment. Les personnes sensibles à ce problème ont été impliquées dans des efforts de normalisation qui devaient lier à un texte chiffré des données en texte clair, telles qu'une adresse IP. Les gens voulaient un moyen bon marché et sûr de le faire lors de l'utilisation d'un mode AE tel que l'OCB
C'est quelque chose que vous voulez utiliser avec les données chiffrées, et assurez-vous qu'elles n'ont pas été modifiées, mais que les besoins (ou peuvent) restent visibles.