Chiffrement authentifié
Le chiffrement authentifié (AE, pour "authenticated encryption") est une construction de chiffrement qui assure simultanément la confidentialité des données (le message est inintelligible sans posséder la clé[1] ) et leur authenticité (il est impossible de modifier un message existant ou d'en créer un nouveau sans posséder la clé). Cette dernière propriété est obtenue en ajoutant au message un code de contrôle, dépendant du contenu du message, et calculable uniquement avec la clé[2] .
Des exemples de modes de chiffrement offrant un chiffrement authentifié sont GCM et CCM . [1]
De nombreuses construction de chiffrement authentifié (mais pas toutes) permettent au message de contenir des « données associées » (AD) qui ne seront pas couvertes par le chiffrement, mais uniquement par l'authentification (c'est-à-dire qu'elles seront intelligibles sans la clé, mais que leur modification invalidera le message entier). Une utilisation typique est la protection d'un paquet réseau dont la destination est contenue dans l'en-tête. Pour acheminer correctement le paquet, tous les nœuds intermédiaires sur le chemin du message doivent pouvoir lire l'adresse du destinataire, mais il n'est pas souhaitable que cette adresse puisse être modifiée.[3]
On nomme de telles constructions chiffrement authentifié avec données associées, ou AEAD . [3]
Interface de programmation
L'interface de programmation d'un chiffrement authentifé offrira typiquement les fonctions suivantes:
- Chiffrement
- Entrée : texte clair, clé et éventuellement un en-tête (également appelé données authentifiées supplémentaires, AAD, ou données associées, AD ). Le texte clair sera chiffré et authentifié; les données associées ne seront pas chiffrées, mais seront authentifiées.
- Sortie : texte chiffré et code d'authentification du message (aussi appelé MAC).
- Déchiffrement
- Entrée : texte chiffré, clé, code d'authentification et éventuellement un en-tête (si utilisé pendant le chiffrement).
- Sortie : texte en clair, avec une garantie que le texte en clair ainsi que l'en-tête sont authentiques, ou une erreur si le code d'authentification n'est pas valable.
Histoire
L'idée d'un chiffrement authentifié est née de l'observation selon laquelle il est en apparence aisé d'assembler un algorithme de chiffrement et un algorithme d'authentification, et de produire une construction vulnérable même quand les algorithmes sous-jacents ne le sont pas individuallement[4],[5]. Cela a été confirmé par l'existence d'un certain nombre d’attaques pratiques sur des protocoles ou des applications déployées en production[6].
Autour des années 2000, un certain nombre d’efforts ont été fournis en direction d'une standardisation de modes garantissant une mise en œuvre correcte. En particulier, un vif intérêt pour les modes sécurisés a été suscité par la publication des variantes CBC authentifiables et parallélisables (IAPM)[7] de Charanjit Jutla (voir OCB et chronologie[8] ).
Six modes de chiffrement authentifié différents ont été définis par la norme ISO/IEC 19772:2009, à savoir les mode OCB (Offset Code Book), Key Wrap, CCM (Counter with CBC-MAC), EAX, EtM (Encrypt-then-MAC), et GCM (Galois/Counter Mode) ont été normalisés dans la norme ISO/IEC 19772:2009[9]. Des méthodes de chiffrement authentifié supplémentaires ont été développées en réponse à la demande du NIST[10]. Les fonctions éponges peuvent être utilisées en mode duplex pour fournir un chiffrement authentifié[11].
Bellare et Namprempre (2000) ont analysé trois méthodes d'assemblage de chiffrement et de MAC, et ont démontré que le chiffrement d'un message suivi de l'application d'un MAC au texte chiffré (l'approche Encrypt-then-MAC) fournit la résistance à une attaque interactive à texte chiffré choisi, à condition que les deux fonctions sous-jacentes répondent à certains de prérequis. Katz et Yung ont étudié cette notion sous le nom de « chiffrement infalsifiable » et ont prouvé qu'elle impliquait une sécurité contre les attaques à texte chiffré choisi[12].
En 2013, le concours CAESAR a été ouvert pour encourager la conception de nouveaux modes de chiffrement authentifié[13].
En 2015, ChaCha20-Poly1305 est ajouté, comme alternative au mode GCM, dans la liste des constructions recommandées l'IETF.
Variantes
Chiffrement authentifié avec données associées
Le chiffrement authentifié avec données associées (Authenticated Encryption with Associated Data, ou AEAD) est une variante de chiffrement authentifié qui permet d'ajouter au message confidentiel des « données associées » non confidentielles mais dont l'authenticité est importante. Le destinataire peut simultanément vérifier l’intégrité du message confidentiel et de ses données associées. l'AEAD est utile, par exemple, dans les paquets réseau, dont l'en-tête doit être en accessible en clair pour le routage, mais le contenu doit être confidentiel, les deux nécessitant intégrité et authenticité . La notion d'AEAD a été formalisée par Rogaway (2002). [3]
AEAD avec engagement sur clé
Le mode AE a été conçu à l'origine principalement pour assurer l'intégrité du texte chiffré : la validation réussie d'un code d'authentification par Alice à l'aide de sa clé symétrique K A indique que le message n'a pas été falsifié par un adversaire Mallory qui ne possède pas la K A. Les schémas AE ne fournissent généralement pas l' engagement envers une clé, une garantie que le déchiffrement échouerait pour toute autre clé. [14] En 2021, la plupart des schémas AE existants (y compris le très populaire GCM) permettent l'authentification sans erreur d'un message généré avec une clé K A (correcte) lorsqu'il est déchiffré avec une deuxième clé K M (erronée), c'est-à-dire que le contenu du texte clair déchiffré sera incorrect, mais le code d'authentification sera considéré valable[15]. Étant donné que l’élaboration d’un message avec une telle propriété nécessite que Mallory possède déjà les clés K A et K M, la question pourrait sembler être d’un intérêt purement académique. [16] Toutefois, dans des circonstances particulières, cette propriété débouche sur des attaques pratiques. Par exemple, si un protocole d'authentification d'identité utilise comme preuve d'identité la génération d'un message chiffré avec une clé dérivée d'un mot de passe, la capacité de créer un message passant la vérification d'authenticité pour un grand nombre de clés différentes permet d'accélérer considérablement une attaque en ligne, dans le cas ou le système d'authentification est utilisable comme un oracle . Naturellement, cette attaque est irréalisable en pratique si les clés sont générées aléatoirement (au lieu d'être dérivées d'un mot de passe)[17].
L'engagement sur clé a été initialement étudié dans les années 2010 par Abdalla et al. [18] et Farshim et al. [19], sous le nom de « chiffrement robuste ». [16],[20]
Pour neutraliser l'attaque décrite ci-dessus lorsqu'il n'est pas possible d'éliminer l'oracle, il est possible d'utiliser un chiffrement AEAD à engagement sur clé qui interdit l'existence de tels messages (passant la vérification d'intégrité avec succès pour plusieurs clés différentes). AEGIS est un exemple de construction AEAD rapide (si le jeu d'instructions AES est présent) et offrant l'engagement envers une clé[21]. Il est possible d'ajouter l'engagement sur clé à un schéma AEAD existant[22].
Assemblage d'un chiffrement authentifié
Chiffrement-puis-MAC (Encrypt-then-MAC, ou EtM)
Le texte en clair est d’abord chiffré, puis un MAC est calculé sur le texte chiffré résultant. Le texte chiffré et son MAC sont transmis conjointement. EtM est la méthode d'assemblage standard recommandée par la norme ISO/IEC 19772:2009[9]. C'est la seule méthode qui peut atteindre la définition de sécurité la plus élevée pour le chiffrement authentifié, mais cela ne peut être réalisé que lorsque le MAC utilisé est « fortement infalsifiable » (c'est-à-dire qu'il est impossible, étant donné un message et un code d'authentification correct, de calculer un autre code d'authentification également correct pour le même message)[23].
IPSec a adopté un fonctionnement de type EtM en 2005[24].
En novembre 2014, TLS et DTLS ont reçu des extensions pour EtM avec la RFC 7366[25]. Il existe également diverses suites de chiffrement EtM pour SSHv2 (par exemple, hmac-sha1-etm@openssh.com ).
Chiffrement-et-MAC (Encrypt-and-MAC, E&M)
Un MAC est calculé sur le texte en clair, et le texte en clair est chiffré indépendamment du MAC. Le MAC du texte en clair et le texte chiffré sont envoyés ensemble. Ce mode est utilisé par exemple dans SSH[26]. Même si l'approche E&M n'a pas été prouvée comme étant intrinsèquement fortement infalsifiable[23] il est possible d'appliquer quelques modifications mineures à SSH pour obtenir l'infalsifiabilité forte dans ce cas particulier[27].
MAC-puis-Chiffrement (Mac-then-Encrypt, MtE)
Un MAC est calculé sur le texte en clair, puis le texte en clair et le MAC sont concaténés et le résultat est chiffré. Le texte chiffré (contenant le MAC) est transmis. Jusqu'à TLS 1.2, toutes les suites de chiffrement SSL/TLS disponibles utilisaient une construction de type MtE[28].
La construction MtE n'offre pas intrinsèquement l'infalsifiabilité forte[23]. Dans le cas particulier de SSL/TLS, Krawczyk a établi une preuve que SSL/TLS offrait l'infalsifiabilité forte, en raison du codage particulier utilisé avec le mécanisme MtE[29]. Cependant, la preuve de Krawczyk dépendait du caractère aléatoire du vecteur d’initialisation (IV). L'attaque BEAST de 2011 exploitait le caractère prévisible des IVs dans une chaîne de messages, ce qui compromettait tous les algorithmes CBC présents dans TLS 1.0 et inférieurs[30].
De plus, une analyse plus approfondie de SSL/TLS précise que le modèle utilisé est MAC-puis-rembourrage-puis-chiffrement, c'est-à-dire que le texte en clair est d'abord agrandi pour s'aligner sur la taille du bloc de la fonction de chiffrement, selon un schéma de rembourrage précis. Lorsque l'utilisation d'un rembourrage incorrect déclenche une erreur, si l'attaquant est capable de distinguer une erreur de rembourrage d'un MAC erroné, il obtient alors un oracle de rembourrage utilisable pour attaquer le chiffrement. Un exemple d'une telle attaque est Lucky Thirteen .
Notes et références
- Black 2005, p. 1.
- ↑ Katz et Lindell 2020, p. 116.
- Black 2005, p. 2.
- ↑ M. Bellare, P. Rogaway et D. Wagner, « A Conventional Authenticated-Encryption Mode », NIST (consulté le ) : « people had been doing rather poorly when they tried to glue together a traditional (privacy-only) encryption scheme and a message authentication code (MAC) »
- ↑ T. Kohno, J. Viega et D. Whiting, « The CWC Authenticated Encryption (Associated Data) Mode », NIST (consulté le ) : « it is very easy to accidentally combine secure encryption schemes with secure MACs and still get insecure authenticated encryption schemes »
- ↑ « Failures of secret-key cryptography » [archive du ], Daniel J. Bernstein (consulté le )
- ↑ Jutl, « Encryption Modes with Almost Free Message Integrity », Cryptology ePrint Archive: Report 2000/039, IACR, (consulté le )
- ↑ T. Krovetz et P. Rogaway, « The Software Performance of Authenticated-Encryption Modes », Fast Software Encryption 2011 (FSE 2011), IACR, (lire en ligne)
- « Information technology -- Security techniques -- Authenticated encryption », 19772:2009, ISO/IEC (consulté le )
- ↑ « Encryption modes development », NIST (consulté le )
- ↑ The Keccak Team, « Duplexing The Sponge »
- ↑ J. Katz et M. Yung, Fast Software Encryption (FSE): 2000 Proceedings, vol. 1978, coll. « Lecture Notes in Computer Science », , 284–299 p. (ISBN 978-3-540-41728-6, DOI 10.1007/3-540-44706-7_20), « Unforgeable Encryption and Chosen Ciphertext Secure Modes of Operation »
- ↑ « CAESAR: Competition for Authenticated Encryption: Security, Applicability, and Robustness » (consulté le )
- ↑ Albertini et al. 2020, p. 1-2.
- ↑ (en-US) « Invisible Salamanders Are Not What You Think », Dhole Moments, (consulté le )
- Albertini et al. 2020, p. 2.
- ↑ (en) Julia Len et Paul Grubbs « Partitioning Oracle Attacks » () (lire en ligne)
—USENET '21 - ↑ Abdalla, Bellare et Neven 2010, p. 480–497.
- ↑ Farshim et al. 2013, p. 352–368.
- ↑ Bellare et Hoang 2022, p. 5.
- ↑ (en) Denis, « The AEGIS Family of Authenticated Encryption Algorithms », cfrg.github.io
- ↑ Gueron, « Key Committing AEADs »,
- « Authenticated Encryption: Relations among notions and analysis of the generic composition paradigm » [archive du ], M. Bellare and C. Namprempre (consulté le )
- ↑ Kent, « Separate Confidentiality and Integrity Algorithms », RFC 4303 - IP Encapsulating Security Payload (ESP), Internet Engineering Task Force (IETF), (lire en ligne, consulté le )
- ↑ (en) Request for comments no 7366
- ↑ Lonvick et Ylonen, « Data Integrity », RFC 4253, Internet Engineering Task Force (IETF), (lire en ligne, consulté le )
- ↑ Bellare, Kohno et Namprempre, « Breaking and Provably Repairing the SSH Authenticated Encryption Scheme: A Case Study of the Encode-then-Encrypt-and-MAC Paradigm », ACM Transactions on Information and System Security (consulté le )
- ↑ Rescorla et Dierks, « Record Payload Protection », RFC 5246, Internet Engineering Task Force (IETF), (lire en ligne, consulté le )
- ↑ « The Order of Encryption and Authentication for Protecting Communications (Or: How Secure is SSL?) », H. Krawczyk (consulté le )
- ↑ Duong et Rizzo, « Here Come The ⊕ Ninjas », – BEAST attack whitepaper
Voir aussi
Bibliographie
- J. Katz et Y. Lindell, Introduction to Modern Cryptography, CRC Press, coll. « Chapman & Hall/CRC Cryptography and Network Security Series », (ISBN 978-1-351-13301-2, lire en ligne)
- J. Black, Encyclopedia of Cryptography and Security, Springer US, , 11–21 p. (ISBN 978-0-387-23473-1, DOI 10.1007/0-387-23483-7_15), « Authenticated encryption »
- Albertini, Duong, Gueron, Kölbl, Luykx et Schmieg, « How to Abuse and Fix Authenticated Encryption Without Key Commitment », USENIX,
- Bellare et Hoang, « Efficient Schemes for Committing Authenticated Encryption », EUROCRYPT 2022,
- Michel Abdalla, Mihir Bellare et Gregory Neven, Theory of Cryptography, vol. 5978, Springer Berlin Heidelberg, (ISBN 978-3-642-11798-5, DOI 10.1007/978-3-642-11799-2_28), « Robust Encryption »
- Pooya Farshim, Benoît Libert, Kenneth G. Paterson et Elizabeth A. Quaglia, Public-Key Cryptography – PKC 2013, vol. 7778, Springer Berlin Heidelberg, (ISBN 978-3-642-36361-0, DOI 10.1007/978-3-642-36362-7_22), « Robust Encryption, Revisited »
- John Chan et Phillip Rogaway, Computer Security – ESORICS 2022, vol. 13555, Springer Nature Switzerland, (ISBN 978-3-031-17145-1, DOI 10.1007/978-3-031-17146-8_14), « On Committing Authenticated-Encryption »
Articles connexes
- Portail de la cryptologie