Protecting Cryptographic Libraries against Side-Channel and Code-Reuse Attacks
Ce papier analyse les vulnérabilités de sécurité des bibliothèques cryptographiques populaires face aux attaques par canaux auxiliaires et aux corruptions de mémoire, évalue leurs défenses actuelles et propose des améliorations pour leurs processus de développement.
Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète
Imaginez les bibliothèques cryptographiques comme les coffres-forts high-tech d'Internet. Ce sont les outils logiciels qui verrouillent vos mots de passe, chiffrent vos messages et vérifient votre identité. Sans elles, notre monde numérique serait grandement ouvert. Cependant, cet article soutient que même les meilleurs coffres-forts présentent des points faibles, et que les personnes qui les construisent (les développeurs) ainsi que les outils qu'elles utilisent pour les construire (les compilateurs) ne font pas toujours assez pour les protéger.
Voici une décomposition des points principaux de l'article à l'aide d'analogies simples.
1. Les Deux Types de Voleurs
L'article identifie deux façons principales dont les attaquants tentent de pénétrer ces coffres-forts numériques :
Le « Voleur au Chronomètre » (Attaques par Canal Auxiliaire) :
Imaginez un voleur qui ne tente pas de crocheter la serrure. Au lieu de cela, il se tient à l'extérieur du coffre-fort et écoute. Il remarque que lorsque le gardien essaie une clé spécifique, la porte du coffre-fort met légèrement plus de temps à claquer que lorsqu'il essaie une mauvaise clé. En chronométrant ces minuscules différences, le voleur peut découvrir le code secret sans jamais toucher la serrure.- Le Point de l'Article : Le code cryptographique contient souvent des étapes « dépendantes du secret ». Si le code prend des durées d'exécution différentes selon un mot de passe secret, un pirate peut utiliser un chronomètre pour voler ce mot de passe.
Le « Pirate Copier-Coller » (Attaques par Réutilisation de Code) :
Imaginez une bibliothèque où les livres sont écrits dans un langage désordonné et peu sûr. Un voleur trouve un trou dans le sol (une erreur de mémoire) et y fait tomber une bombe qui brise les planches. Une fois le sol brisé, le voleur n'a pas besoin de construire une nouvelle arme ; il se contente de saisir un marteau, une scie et une échelle qui étaient déjà entreposés dans le local de stockage de la bibliothèque. Il « assemble » ces outils existants pour sortir et prendre le contrôle du bâtiment.- Le Point de l'Article : De nombreuses bibliothèques sont écrites dans des langages comme le C ou le C++ qui permettent des erreurs de mémoire. Les pirates exploitent ces erreurs pour détourner le flux du programme, en utilisant de petits morceaux de code inoffensifs déjà présents dans la bibliothèque pour lancer une attaque massive.
2. L'État Actuel du Coffre-Fort
Les auteurs ont examiné 11 bibliothèques cryptographiques populaires (comme OpenSSL, utilisée par des millions de sites web) pour évaluer leur niveau de protection.
- Le Problème du « Chronomètre » : La plupart des développeurs connaissent les attaques par chronométrage et tentent de les corriger en écrivant un code qui prend exactement le même temps d'exécution, quelle que soit la situation. Cependant, l'article a révélé que seulement 2 bibliothèques sur 11 testent réellement leur produit final pour s'assurer que l'astuce du « chronomètre » ne fonctionne pas. C'est comme un chef qui goûte la soupe avant de la servir, mais oublie de vérifier si le sel est vraiment dissous.
- Le Problème du « Copier-Coller » : Les développeurs utilisent des outils de sécurité standards (comme les « canaris de pile », qui agissent comme des pièges) pour prévenir les erreurs de mémoire. Bien que ces outils aident, ils ne sont pas parfaits. L'article a constaté que la plupart des bibliothèques n'utilisent pas les paramètres de sécurité les plus robustes disponibles, les laissant vulnérables à des détournements sophistiqués.
3. Le Plan Défectueux (Le Problème du Compilateur)
C'est le cœur de l'argument de l'article. Les développeurs écrivent le code (le plan), mais un compilateur est la machine qui traduit ce plan en code machine fonctionnel réel.
- Le Conflit : Les compilateurs sont conçus pour rendre le code rapide et efficace. Ils agissent comme un éditeur très zélé qui souhaite éliminer tout « remplissage » pour raccourcir l'histoire.
- L'Erreur : Parfois, le « remplissage » que le compilateur élimine est en réalité une mesure de sécurité. Par exemple, un développeur peut écrire du code supplémentaire pour s'assurer qu'un processus prend le même temps (pour arrêter le Voleur au Chronomètre). Le compilateur, pensant que ce code supplémentaire est un gaspillage inutile, le supprime. Le résultat ? Le code redevient rapide, mais la faille de sécurité réapparaît.
4. Nouveaux Outils pour la Tâche (Compilation Sécurisée)
L'article suggère que nous avons besoin d'un nouveau type d'« éditeur » ou de compilateur qui comprend la sécurité aussi bien qu'il comprend la vitesse. Ils ont testé quatre outils expérimentaux différents :
- Le « Gardien » (SecComp) : Cet outil permet aux développeurs de marquer certaines parties du code comme « ne pas toucher ». Il force le compilateur à maintenir les mesures de sécurité en place. Inconvénient : Il n'est pas encore gratuit à utiliser.
- Le « Mélangeur » (Multicompiler/MCR) : Cet outil prend le code et réarrange les meubles à chaque fois qu'il construit le programme. C'est comme déplacer le marteau et la scie dans différentes pièces chaque jour. Si un voleur s'introduit, il ne peut pas trouver les outils dont il a besoin car la disposition a changé. Inconvénient : Il ralentit considérablement le programme s'il est utilisé pour arrêter le « Voleur au Chronomètre ».
- L'« Architecte » (SecDivCon) : Cet outil construit le code avec des règles de sécurité intégrées dès le départ, garantissant que le produit final est à la fois rapide et sûr. Inconvénient : Sa construction prend très longtemps et il ne fonctionne bien que pour des tâches petites et spécifiques.
- Le « Linéariseur » (PCFL) : Cet outil réécrit automatiquement le code désordonné en une ligne droite et prévisible impossible à chronométrer. Inconvénient : Il n'arrête pas les attaques du « Pirate Copier-Coller ».
5. Le Verdict Final
L'article conclut que nous sommes actuellement coincés dans un fossé entre vitesse et sécurité.
- Les développeurs tentent d'écrire du code sécurisé manuellement, mais ils manquent souvent leur cible.
- Les compilateurs sont trop focalisés sur la vitesse et suppriment accidentellement des fonctionnalités de sécurité.
- Les outils actuels sont soit trop lents, trop complexes, ou ne couvrent pas tous les types d'attaques.
La Solution : Les auteurs appellent à un effort à trois volets :
- Les fabricants de compilateurs doivent donner plus de contrôle aux développeurs afin qu'ils puissent dire : « Ne supprimez pas cette fonctionnalité de sécurité, même si elle semble lente. »
- Les fabricants de compilateurs sécurisés doivent créer des outils capables de gérer à la fois les attaques par chronométrage et les détournements simultanément, et non pas l'un ou l'autre.
- Les développeurs de bibliothèques doivent cesser de compter sur l'espoir et commencer à utiliser ces nouveaux outils de compilation plus sûrs pour s'assurer que leurs coffres-forts sont véritablement verrouillés.
En bref : Nous avons les plans pour des coffres-forts sûrs, mais les machines qui les construisent sont trop pressées de faire des compromis. Nous devons apprendre aux machines à privilégier la sécurité autant que la vitesse.
Noyé(e) sous les articles dans votre domaine ?
Recevez des digests quotidiens des articles les plus récents correspondant à vos mots-clés de recherche — avec des résumés techniques, dans votre langue.