Alors que nous nous rapprochons d'un monde post-quantique, tous les regards se tournent vers le NIST (National Institute of Standards and Technology).
Le NIST est l'organisme chargé de normaliser un algorithme spécialement conçu pour résister aux attaques des ordinateurs quantiques. Le processus de sélection processus de sélection pluriannuel approche de sa phase finale, avec trois algorithmes (BIKE, Classic McEliece et HQC) ont passé avec succès un processus de test rigoureux en 2023 et sont parvenus au quatrième tour.
Aujourd'hui, ces algorithmes sont un peu plus proches d'être accessibles aux organisations du monde entier pour qu'elles les intègrent dans leur infrastructure de chiffrement. Mais ce n'est pas encore le cas.
La dernière étape du processus de normalisation a été la suivante la cinquième conférence du NIST sur la normalisation des CQPdu NIST, qui s'est tenue en avril à Rockville, dans le Maryland.
L'objectif de la conférence était de discuter des différents aspects des algorithmes et d'obtenir un retour d'information précieux qui permettra de prendre des décisions en matière de normalisation. Les équipes de soumission pour BIKE, Classic McEliece, Falcon et HQC ont également présenté une mise à jour de leurs algorithmes.
J'ai eu l'occasion d'assister à la conférence et voici ce que j'en retiens.
Mais d'abord, pourquoi c'est important...
Avant d'entrer dans les détails de la conférence de normalisation du CQP, il convient de préciser l'importance de ce processus.
La cryptographie quantique arrive, et bien que personne ne sache exactement quand elle arrivera, nous savons qu'une fois que les premiers ordinateurs quantiques seront en service, la plupart de nos algorithmes de cryptage actuels deviendront obsolètes.
Ainsi, bien que nos algorithmes actuels puissent encore nous protéger contre les menaces non quantiques, les experts soulignent la nécessité d'une planification proactive pour garantir la sécurité à long terme. Cela est d'autant plus important que l'intégration de nouveaux algorithmes dans tous les systèmes informatiques peut prendre du temps et s'étaler sur plusieurs années.
En conséquence, l'industrie et les organisations gouvernementales font la course contre la progression de la PQC pour mettre en œuvre de nouvelles normes. Le(s) algorithme(s) sélectionné(s) par le NIST fournira(ont) ces normes, offrant au monde les premiers outils pour protéger les informations sensibles contre cette nouvelle menace.
Une nouvelle phase signifie de nouveaux défis
Le NIST a annoncé qu'il publierait les normes fédérales de traitement de l'information (FIPS) 203, 204 et 205 vers l'été 2024. Cette annonce a incité chacun des candidats de la quatrième série à partager des mises à jour sur la façon dont ils prévoient d'aller de l'avant. Plusieurs candidats ont également abordé les problèmes récemment découverts avec leurs algorithmes. Voici les principaux messages de chacun d'entre eux :
VÉLO
L'équipe BIKE a répondu à un article attaquant son algorithme, affirmant que l'attaque n'était pas réalisable dans la pratique, et a proposé une modification de l'implémentation pour y remédier.
McEliece classique
L'équipe de Classic McEliece reste ferme sur son algorithme. Elle affirme qu'il est le plus stable de tous les autres algorithmes PQC, citant plusieurs projets qui l'ont utilisé, notamment Adva dans les réseaux optiques à haut débit, crypt4a dans HSM, software implémentations comme Bouncy Castle, et des VPN comme MULLVAD VPN et ROSENPASS.
Faucon
L'équipe Falcon (ainsi que le NIST) publiera une première version à l'automne 2024. Ils ont mentionné la difficulté de mettre en œuvre l'arithmétique en virgule flottante et les problèmes qu'elle pourrait révéler, partageant la façon dont ils prévoient d'adopter des caractéristiques de l'algorithme Hawk, qui utilise ANTRAG pour réduire la quantité d'opérations arithmétiques en virgule flottante.
HQC
L'équipe HQC a publié de nouvelles preuves de sécurité qui n'ont aucun effet sur l'état actuel de l'implémentation ou de ses entrées et sorties. Elle a également proposé une contre-mesure pour une récente attaque de synchronisation et un correctif pour son attaque de canal latéral de synchronisation modulaire par détournement.
Les nouvelles normes FIPS entraînent des changements supplémentaires
Le NIST a fait plusieurs annonces concernant les changements à attendre des nouveaux documents FIPS. Le document FIPS 203 pour Kyber/ML-KEM subira des modifications importantes. Ces changements comprennent l'inversion de l'indexation de la matrice A, qui ne sera plus rétrocompatible, et la modification des vecteurs de test standardisés.
Ensuite, l'échantillon NTT utilisera désormais une API XOF spécifique car la norme existante ne permettait pas l'utilisation de SHAKE en tant que flux. Elle spécifiera également une API dérandomisée de "niveau inférieur", qui permet les tests CAVP, et ne donnera pas d'indications aux KEM dans FIPS 203, mais plutôt dans SP 800-277.
La norme FIPS 204 Dilithium/ML-DSA connaîtra également des changements importants. La fonction SampleInBall sera modifiée, ce qui entraînera des problèmes de rétrocompatibilité et nécessitera de nouveaux vecteurs de test. Entre-temps, ExpandMask n'utilisera pas de décalage pour la sortie SHAKE, les vérifications manquantes ont été corrigées et les variantes "domain-separated pure" et "pre-hash" ont été introduites.
Enfin, le FIPS 205 ne subira pas de modifications importantes. Le changement le plus important concernera les fonctions internes qui devront prendre en compte le caractère aléatoire pour permettre les tests de la CAVP.
Les attaques par canal latéral sont au cœur des préoccupations
Les canaux latéraux ont été évoqués à plusieurs reprises, et de nombreuses conversations ont eu lieu sur la manière d'éviter ces attaques.
Un orateur a expliqué comment il a rendu Sphincs+ résistant aux canaux latéraux, mais cela a réduit les performances de l'implémentation de référence de 70 %. Par ailleurs, un autre orateur a fait part de son expérience en combinant plusieurs fuites physiques faibles de HQC pour récupérer la clé partagée à l'aide de SASCA ; toutefois, cette expérience n'était applicable qu'à l'implémentation de référence de HQC et non à la version optimisée.
Notamment, une session sur le sujet a utilisé des réseaux neuronaux pour attaquer la fonction de déballage de clé de Dilithium et récupérer la clé secrète. Dilithium a répondu qu'elle considérait la fonction de déballage comme protégée et a suggéré de masquer statiquement la clé stockée, d'effectuer un codage à poids constant ou de mélanger la boucle de déballage de la clé pour éviter les vulnérabilités.
Planifier la transition vers le CQP
Bien que les normes n'aient pas encore été finalisées, les organisations du monde entier doivent garder à l'esprit la transition vers le CQP. C'est pourquoi la préparation de cette transition a été un sujet important lors de la conférence.
Les activités clés de la transition comprennent l'identification de tous les objets PKI et de leur durée de vie dans le système, la préparation des formats de données et des contraintes technologiques, ainsi que la mise en œuvre et l'utilisation des outils open-source disponibles.
Les identifiants d'algorithmes, le codage des objets, la sensibilisation à l'interopérabilité et les jetons cryptographiques sont quelques-uns des obstacles courants que les organisations rencontrent déjà dans le domaine de l'ingénierie post-quantique. En particulier, les OID ASN.1 sont très désordonnés et doivent être plus unifiés. Heureusement, des efforts sont en cours pour y remédier. page GitHub de l'IETF Hackathonqui contient un tableau des OIDs actuels.
Comprendre l'impact de la CQP sur les connexions dans le monde réel
L'une des questions soulevées concernait l'effet de la PQC sur les connexions réelles telles que TLS 1.3.
En bref, les algorithmes PQC ralentissent le processus d'échange de données pour TLS. Cela dit, plus une page web a besoin de données, moins elle a d'impact sur le ralentissement de la poignée de main. Par conséquent, le fait de ne considérer que la vitesse de la poignée de main n'est pas un moyen viable de mesurer l'efficacité, car les données envoyées sont importantes.
Les signatures numériques restent un point d'intérêt important
Les méthodes utilisées dans le nouveau cycle de signatures ont fait l'objet de nombreuses conversations, en particulier la manière dont les arbres GGM ont été optimisés pour être utiles dans les algorithmes de signature.
Plus précisément, ANTRAG simplifie et améliore Falcon sans compromettre la sécurité en utilisant un échantillonneur hybride plutôt qu'un échantillonneur kgpy. Par conséquent, l'utilisation d'ANTRAG permet d'obtenir un schéma de signature beaucoup plus simple, avec des performances améliorées et sans perte de sécurité - c'est pourquoi l'équipe Falcon est intéressée par l'adaptation de cette approche dans son algorithme. Cependant, cette approche n'élimine pas le problème de la virgule flottante auquel le NIST est actuellement confronté (mais elle le réduit).
Des recherches ont également été menées sur les jeux de paramètres Sphincs+ pour des cas d'utilisation spécifiques. Pour des cas d'utilisation tels que la signature de firmware, il est redondant d'avoir une capacité de signature maximale aussi élevée, et l'abaissement de cette limite permet de réduire la taille de la signature de 50 % et d'améliorer la vérification de 80 %. Le risque de cette approche est que le suivi du nombre de signatures le transforme en quelque chose d'étatique, auquel cas il existe de meilleures options que Sphincs+. En outre, le fait d'avoir des limites d'utilisation basses a posé des problèmes dans le passé, comme dans le cas de l'AES-GCM.
Enfin, plusieurs exposés sur hardware ont porté sur les nouveaux algorithmes de signature et la théorie qui les sous-tend. L'un des exposés a mentionné une nouvelle conception de BIKE, appelée BIKE allégé, qui renonce à la sécurité de l'ACC au profit de meilleures performances et d'une mise en œuvre plus simple. Des discussions ont également eu lieu sur la question de savoir si les KEM multi-bénéficiaires pouvaient assurer la synchronisation des états dans les flottes de HSM et rendre le MLS treeKEM plus efficace.
Peut-on accélérer le hachage ?
Un exposé a abordé l'accélération de SLH-DSA de deux ordres de grandeur, mais seulement pour hardware. Malheureusement, il est difficile d'accélérer software car une grande partie du goulot d'étranglement provient du hachage et les accélérateurs de hachage sont conçus pour hacher des données, pas d'autres hachages, il est donc difficile d'accélérer ce processus.
Qu'est-ce que cela signifie ? La CQP approche à grands pas et c'est maintenant qu'il faut s'y préparer.
La cinquième conférence de normalisation PQC du NIST a été riche en conversations prospectives sur ce que l'on peut attendre d'un monde post-quantique, sur les changements qui se produisent aujourd'hui et sur les défis à relever. Ce qu'il faut retenir, c'est que la PQC sera là avant que nous le sachions, et qu'il reste encore beaucoup à faire pour s'y préparer.
C'est dans ce but que le Le NIST continuera à travailler à la normalisation des algorithmes définitifs et à apporter des modifications supplémentaires pour maintenir la sécurité dans le monde postquantique. et apportera des modifications supplémentaires pour maintenir la sécurité dans un monde post-quantique. Parallèlement, chaque organisation doit commencer à se préparer au changement d'algorithme et à tout autre changement que le NIST pourrait recommander à l'approche de la CQP.
Besoin d'aide pour démarrer ? KeyfactorL'équipe d'experts de PKI peut vous aider à pérenniser votre stratégie PKI . Contactez-nous ici.
