Il y a peu, nous avons découvert un article de cio-online.com proposant selon le titre « 7 façons de mieux crypter ses données » qui a fait lever quelques sourcils dans notre centre d’expertise cryptographie.
Nous l’avons donc analysé, et avons par la suite décidé de répondre à une question soulevée par cet article mais auquel il ne répondait pas.
Cette analyse nous laisse à penser qu’un LLM a été utilisé pour traduire un article initialement en allemand vers le français, où les hallucinations du LLM ont engendré quelques problèmes de cohérences dans l’article.
Démystification de l’article
https://www.cio-online.com/actualites/lire-7-facons-de-mieux-crypter-ses-donnees-16331.html
L’article propose donc différentes choses qui semblent surprenantes pour le chiffrement de données :
- Utiliser des blockchains tels que Solana ou Arbitrum -> blockchain dont les cas d’usage courants n’incluent pas le chiffrement de données
- Utiliser de « l’apprentissage fédéré chiffré » -> L’apprentissage fédéré ne semble pas relever directement du chiffrement, mais de l’usage de la donnée chiffrée
- Utiliser du chiffrement homomorphe -> Le chiffrement homomorphe ne vise pas à chiffrer de la donnée, mais à chiffrer des opérations de calcul de sorte à garantir du Confidential Computing
Nous pourrions continuer à relever d’autres incohérences, néanmoins, la méthode OSINT nous permet d’expliquer l’origine de ces incohérences.
En effet, dans son titre, on trouve « Florian Maier et Peter Wayner, CIO DE (adapté par E.Delsol) », et un peu d’OSINT (recherche en source ouverte) nous permet rapidement de retrouver l’article d’origine en allemand :
Le titre de cet article pourrait être traduit par « 7 façons de (mieux) crypter les données », ce qui est déjà beaucoup plus logique, puisqu’il n’est plus question d’optimisation du chiffrement, mais de méthodes.
A partir de là, on comprend ce qui s’est passé. La traduction a été faite via un LLM qui a pris quelques « libertés » de traduction, ce qui explique par exemple que le projet FrodoPIR dans l’article original est devenu FrodPIR après passage dans le LLM.
Figure 1 – On voit ici l’importance de bien spécifier le nom du projet
Dans le même genre, le projet github Awesome Homomorphic Encryption est devenu « awesome homomorphic development », ce qui illustre l’importance de faire attention aux hallucinations des LLM.
Cependant, cet article a soulevé une vraie problématique qui est l’accélération du chiffrement ou déchiffrement de la donnée. Ce à quoi nous allons tenter de répondre maintenant.
Quelques façons de réellement accélérer le chiffrement/déchiffrement de donnée
Pour commencer, dans l’absolu, nous parlerons uniquement de chiffrement, de déchiffrement et d’un peu de vérification d’intégrité, pas de fonction de signature poussée ou d’homorphisme ou de blockchain… 😉
Ensuite, nous allons préciser que bien souvent, la performance est antagoniste de la sécurité (nous préciserons donc dans un petit texte bleue tout risque lié à une optimisation). Ce qui signifie que chercher à accélérer un processus cryptographique a souvent comme effet de bord de le rendre vulnérable.
Optimisation par le hardware
Il existe plusieurs façons d’optimiser du chiffrement avec le hardware, on peut notamment citer les technologies de FDE pour le stockage et les AES-NI des CPU.
Le Full Disk Encryption est une technologie consistant à fournir à un SSD un mot de passe de chiffrement/déchiffrement et laisser le contrôleur du disque effectuer toutes les opérations directement au plus près du stockage. En comparaison avec un chiffrement du stockage avec une technologie comme BitLocker, que Microsoft a décidé de rendre obligatoire pour tous dès Windows 11[1], la consommation CPU d’une approche FDE est nulle puisque le chiffrement est déporté sur le contrôleur du disque.
Cette méthode repose toutefois sur la confiance accordée au disque, un disque vulnérable, backdooré ou dysfonctionnel rendra nulle l’approche FDE.
L’usage des AES Instruction Set (appelés AES-NI) est une approche consistant à utiliser des instructions spéciales du CPU pour effectuer des opérations cryptographiques courantes, ces dernières étant conçues sur mesure pour certains algorithmes, comme l’algorithme de chiffrement/déchiffrement AES. Suivant le module utilisé pour chiffrer/déchiffrer, ces instructions peuvent être utilisées automatiquement. Néanmoins, vérifier leur application et les activer le cas échéant peut faire gagner en performance. Il peut aussi être intéressant de sélectionner des CPU en fonction de la performance de leur instruction set[2].
Cette méthode repose toutefois sur la confiance accordée au CPU, un CPU backdooré (bien que très improbable) affaiblira le chiffrement.
(Il est à noter que d’autres fonctionnalités tels que AVX et PCMUL permettent l’optimisation de ces fonctions, mais nous ne donnons l’exemple que pour AES-NI)
Optimisation par le système
Les optimisations précédentes proposées partent du principe que les fonctions cryptographiques choisies sont les bonnes. Mais une autre façon d’optimiser le chiffrement/déchiffrement de données est aussi de choisir le bon algorithme en fonction du Système. Pour cela, les questions suivantes peuvent être posées :
- Quel est le niveau de sécurité visé ? Au bout de combien de temps les données chiffrées ne peuvent plus servir à nuire si elles fuitent ? Cela peut conditionner le choix entre par exemple AES-128 et AES-256 : les opérations utilisant ce dernier prendront plus de temps à s’effectuer que le premier. Si les données chiffrées et la clef correspondante ne sont utiles qu’un jour, sachant qu’AES peut prendre des années à casser, on pourra se permettre de choisir le moins gourmand des deux.
- Quelles sont mes contraintes matérielles ? Y-a-t-il beaucoup de RAM ? Un processeur ou un coprocesseur suffisamment puissant ou avec certaines limitations ? Ces questions rejoignent l’optimisation par le matériel, mais sous l’angle selon lequel on pourrait avoir d’autres contraintes fonctionnelles qui conditionnent l’environnement matériel cible.
- L’OS dispose-t-il de notion de priorisation permettant de prioriser les fonctions crypto ?
- Est-il possible de précharger lesdites fonctions cryptographiques ou de les garder en mémoire continuellement pour en bénéficier au plus vite ?
Optimisation par le software
Au niveau des fonctions cryptographiques que l’on utilise, d’autres optimisations sont possibles pour accélérer leur processus. Avant de rentrer dans des détails cryptographiques, rappelons des méthodes reposant sur la conception logicielle :
- Paralléliser la fonction cryptographique
- La possibilité de paralléliser dépend surtout du mode de chiffrement par bloc, AES-XTS est considéré aujourd’hui comme le plus parallélisable, suivi de GCM et CTR
- Utiliser un langage compilé au plus proche de l’OS (utiliser du C/Go/Rust plutôt que Python, Javascript ou Java par exemple) ou, si ce n’est pas possible, une bibliothèque de fonctions cryptographiques ou une API proche de l’OS.
- Bien séparer en mémoire les opérations cryptographiques des opérations annexes pouvant ralentir l’exécution (exemple : les opérations I/O qui peuvent être réalisés à l’avance ou bufferisés)
Tout ce qui relève de la conception logicielle introduit des vulnérabilités correspondant au mantra « Don’t roll your own crypto » qui pourrait se traduire dans ce contexte par « ne faites pas votre propre implémentation, suivez les standards éprouvés pour éviter d’introduire des vulnérabilités liées à votre contexte ». Il faut donc faire bien attention à l’implémentation que l’on fait de sorte que ces optimisations n’introduisent pas de vulnérabilité Side-Channel ou Business Logic par exemple
Maintenant que les optimisations par conception logicielle ont été évoquées, nous pouvons terminer par deux propositions directement liées aux fonctions cryptographiques :
Il est important de préciser que dans cet exemple, nous ne parlons de chiffrement qu’avec le standard AES, qui est en réalité composé de 3 parties :
- Cipher – fonction de chiffrement/déchiffrement, celle qui est utilisée couramment est Rinjdael
- Le traitement par bloc – fonction de traitement des blocs à chiffrer/déchiffrer
- La vérification d’intégrité – optionnelle mais de plus en plus utilisée, généralement SHA ou Poly1305
Pour optimiser la partie Cipher, il peut être intéressant de regarder ce qui a de meilleure performance. Par défaut Rinjdael est utilisé, mais ChaCha20 est aujourd’hui plus performant.
Pour la vérification d’intégrité, bien souvent elle se fait à la fin du déchiffrement de l’ensemble des données, ce qui est une erreur car cela nécessite de reparcourir toute la donnée. L’usage d’une fonction qui vérifie l’intégrité de la donnée à chaque déchiffrement de bloc (un code correcteur d’erreur – CRC) est une bonne façon d’optimiser ce processus. AES-GCM avec ChaCha20-Poly1305 propose un modèle AEAD similaire, bien qu’il vérifie aussi et surtout l’authenticité de la donnée.
Conclusion
« Premature optimization is the root of all evil » disait Donald Knuth, un des pères de la programmation.
Cette phrase est tout aussi vraie pour la cryptographie car au travers de ces exemples, le constat de la maitrise non pas juste des algorithmes, mais de tout ce qui est autour est absolument nécessaire.
Connaître le hardware sur lequel un algorithme cryptographique est lancé est vital pour optimiser ces fonctions. De même pour la façon dont il est intégré et les choix techniques qui ont mené à sa sélection.
Quant aux LLM, on voit au préambule qu’il vaut mieux éviter de les utiliser pour de la traduction…
Pour aller plus loin
Si l’envie (ou la nécessité) vous prend de mettre en place des fonctions cryptographiques « accéléré », nous recommandons donc vivement de commencer par déterminer le type de contrainte auquel vous faites face.
Un système où le temps, l’espace, la vitesse de calcule et la puissance de calcul sont contraint laissera bien moins de possibilités qu’un système où seule la puissance de calcul ou l’espace sont contraint.
S’appuyer sur de multiples référentiels de benchmark cryptographiques tels que ceux de l’ENISA, du NIST ou encore issu du modèle ECRYPT peuvent largement aider à la sélection de fonction sûres.
En outre, les produits nécessitant des accélérations cryptographiques sont bien souvent des systèmes IoT ou des systèmes où la cryptographie est très consommatrice car critique. Dans ces cas-là, se faire accompagner par des professionnels tels que le CESTI Serma Safety and Security ou une équipe sûreté de fonctionnement lors de la conception du système embarquant les fonctions de cryptographie est salvateur. En particulier lorsqu’il est question de matériel répondant à des exigences de sécurité lourdes comme pêlemêle la toute nouvelle directive RED, les exigences UN ou encore les exigences cryptographiques NIST.
[1] https://windows.developpez.com/actu/361522/Microsoft-ajoute-le-chiffrement-BitLocker-par-defaut-sur-les-PC-Windows-11-configures-avec-un-compte-Microsoft-dans-le-cadre-de-la-mise-a-jour-24H2-diffusee-depuis-le-mois-de-juin/
[2] https://calomel.org/aesni_ssl_performance.html
