Comme vous le savez, la gestion des clés est l'une des tâches les plus difficiles en cryptographie. L'autre jour, le document «Mécanismes de recomposition des clés symétriques» a été publié sous la
cote RFC 8645 . Il est le résultat de deux ans et demi de travail du groupe de recherche CFRG, qui détermine le développement et l'utilisation de la cryptographie dans l'IETF, et il était basé sur de nombreuses années de recherche et l'expérience de spécialistes russes. Ensuite, nous expliquons brièvement quelle est l'essence de cette RFC et pourquoi elle s'est avérée être juste cela.
Une petite frayeur ...
En 2016, deux chercheurs français de l'Institut Inria ont publié une description de l'attaque
Sweet32 . L'idée qu'ils ont utilisée est obscurément simple et basée sur le soi-disant
"problème d'anniversaire" : si nous calculons les valeurs d'une cartographie aléatoire
puis dans environ
les tests dans la séquence résultante coïncident au moins avec deux valeurs. Du point de vue de la cryptographie, cela signifie qu'un chiffrement de bloc avec une longueur de bloc
le bit ne peut plus être chiffré sur une seule clé
blocs de texte en clair.
Cette attaque a déjà été examinée en détail sur
Habré ; ici, nous notons seulement que les auteurs ont profité du fait que certaines bibliothèques cryptographiques largement utilisées n'ont pas modifié la clé de session à temps. Cela nous a permis d'accumuler beaucoup de données et d'utiliser simplement la propriété probabiliste spécifiée si la connexion utilisait un chiffrement par bloc d'une longueur de bloc de 64 bits. Cela a immédiatement provoqué une grave hystérie dans l'environnement quasi cryptographique concernant la nécessité d'un rejet urgent de ces chiffres.
Mais est la longueur du bloc?
En effet, vaut-il la peine d'ostraciser un chiffre juste parce qu'il a une petite longueur de bloc: que se passe-t-il si vous changez la clé périodiquement? Cela peut être fait en utilisant la fonction dite de dérivation de clé (
KDF ). Ces fonctions vous permettent d'obtenir de nouvelles clés basées sur les anciennes, tout en préservant la propriété de caractère aléatoire des clés (voir, par exemple,
cet article ). De telles fonctions, par exemple, sont déterminées par les recommandations de normalisation russes
P 1323565.1.022-2018 et
P 50.1.113-2016 . Cependant, il y a un «mais»: ce sont des conversions assez complexes et pas très rapides construites sur la base de fonctions de hachage, ce qui ralentira considérablement la vitesse de cryptage.
Est-il possible de faire quelque chose plus rapidement?
Une telle tentative a été faite en 2006 dans la
RFC 4357 , où le mécanisme de maillage de clé CryptoPro a été proposé, qui produit une clé dérivée en chiffrant une constante fixe avec un chiffrement par bloc dans un mode de remplacement simple.
C'était un algorithme très rapide, sans pratiquement aucun effet sur la vitesse de cryptage et protégeant contre des situations aussi ridicules que celles utilisées dans Sweet32, et aussi, par exemple, contre les attaques sur les canaux secondaires. Cependant, lors de la conférence Ruscrypto 2015, il a été
démontré qu'une telle transformation réduit la puissance de l'ensemble de clés, c'est-à-dire à chaque nouvelle modification de clé, le nombre de ses options de sélection de clé possibles diminue. L'auteur a noté que cela n'avait pas eu d'impact significatif sur la sécurité, mais il était néanmoins devenu intéressant de savoir si cela pouvait être encore amélioré.
Il s'est avéré pas si simple
Malheureusement, les miracles n'existent pas et il n'est pas possible d'offrir un mécanisme rapide comparable aux KDF conventionnels, cependant, nous pouvons
prouver la sécurité de plusieurs schémas modifiés comme le maillage de clé spécifié pour chaque mode de cryptage spécifique. Ce sont ces mécanismes qui ont été proposés et
justifiés pour le mode gamma CTR largement utilisé (CTR-ACPKM, Advance Cryptographic Prolongation of Key Material) et le développement d'un insert de simulation OMAC (OMAC-ACPKM) à partir de la norme nationale GOST R 34.13-2015.
Les cotes de sécurité pour ces modes sont obtenues à l'aide de ce qu'on appelle l'appareil
"Durabilité prouvée .
"Ces modes ont été adoptés en Russie en tant que recommandations pour la normalisation du
R 1323565.1.017-2018 .
C'est cette façon de travailler avec les clés qui permet aux outils de chiffrement qui implémentent les ensembles de
chiffrement russes TLS 1.2 (définis dans
les recommandations de normalisation R 1323565.1.020-2018 ) de répondre aux exigences de protection cryptographique russe pour les classes élevées.
Travailler à l'IETF
Les mécanismes développés conviennent parfaitement comme réponse à la discussion mentionnée au début de l'article sur la question de savoir s'il doit y avoir des chiffres avec une courte longueur de bloc ou non.
L'élaboration du document correspondant, devenu par la suite RFC 8645, a été commandée par les présidents du CFRG Kenny Paterson et Alexei Melnikov par un groupe international d'experts dirigé par Stanislav Smyshlyaev. Evgeny Alekseev, Ekaterina Smyshlyaeva et Lilia Akhmetzyanova (CryptoPro), Shay Gueron (Université de Haïfa), Daniel Fox Franke (Akamai Technologies), ainsi que l'ancien président de l'IETF Russ House (Vigil Security) ont contribué à l'élaboration du document final. à divers stades, des spécialistes majeurs tels que Mihir Bellare (Université de Californie), Scott Fleurer (Cisco), Yoav Nir (Checkpoint), Dmitry Belyavsky (Cryptocom) et Paul Hoffman (ICANN) se sont joints aux travaux.
Par rapport aux recommandations russes, des mécanismes ACPKM ont été ajoutés à ce RFC pour des modes tels que CBC, CFB et GCM, qui, comme vous l'avez probablement déjà compris, nécessitaient des
preuves distinctes
.Résumé
Comme nous l'avons déjà noté, bien que l'approche proposée ne soit pas à certains égards universelle et nécessite des justifications de sécurité distinctes pour chaque mode individuel, nous récompensons la vitesse élevée, la sécurité contre les attaques comme Sweet32 et, surtout, les attaques de canaux latéraux.