Retrofit or Redesign? Hardware-Validated Constant-Time Defense and Cost Analysis for the M-Step Side-Channel on TrustZone-M

Imaginez que vous soyez le gardien d'un coffre-fort secret, et que la seule façon de l'ouvrir soit de résoudre un casse-tête mathématique complexe. Dans le monde de la sécurité numérique, ce casse-tête est souvent une « inversion modulaire », un calcul utilisé pour verrouiller et déverrouiller des messages. Pendant des années, les experts ont cru que si l'on rendait le temps nécessaire pour résoudre le casse-tête identique à chaque fois, personne ne pourrait voler le secret. C'est ce qu'on appelle la sécurité à « temps constant ». L'idée était que si un voleur ne pouvait pas savoir si vous réfléchissiez intensément ou si vous deviniez simplement la réponse en se basant sur le temps que mettait la porte à s'ouvrir, il serait en sécurité.

Mais un nouveau tour pendable existe : l'attaque par « pas unique » (single-stepping attack). Imaginez un voleur qui ne se contente pas d'attendre que la porte s'ouvre, mais qui possède un chronomètre magique lui permettant de figer le temps après chaque étape du processus de résolution de votre casse-tête. Il peut ainsi observer exactement le chemin que vous empruntez dans le labyrinthe. Si votre labyrinthe possède des raccourcis secrets que vous n'empruntez que lorsque vous connaissez la réponse, le voleur voit que vous prenez le raccourci et apprend votre secret. Cet article explore un choix crucial pour les ingénieurs en sécurité : lorsqu'une vulnérabilité est découverte, faut-il essayer de colmater l'ancien labyrinthe qui fuit pour le rendre uniforme (un « retrofit » ou mise à niveau) ou doit-on le démolir pour construire un nouveau labyrinthe qui n'a aucun raccourci par conception (un « redesign » ou refonte) ? La réponse ne dépend pas seulement de la rapidité ; il s'agit de savoir laquelle des deux options empêche réellement le voleur de découvrir vos secrets.

---

Le Grand Colmatage du Labyrinthe : Retrofit vs Redesign

Dans cette étude, les chercheurs Arash Razban et son équipe ont affronté une faille de sécurité réelle (connue sous le nom de CVE-2025-54764) trouvée dans une bibliothèque populaire utilisée pour protéger les données sur de petits ordinateurs embarqués, comme ceux des cartes à puce ou des dispositifs médicaux. La faille se trouvait dans les routines de « GCD binaire » et d'« inversion modulaire » — essentiellement les moteurs mathématiques qui gèrent les clés secrètes. Un pirate utilisant une technique appelée « M-Step » pouvait figer l'ordinateur après chaque instruction et observer le chemin parcouru par les mathématiques pour voler la clé secrète.

Les chercheurs ont mis en place un combat en tête à tête sur du matériel silicium réel (une puce Cortex-M33) pour voir quelle stratégie de défense fonctionnait le mieux : Le Retrofit ou Le Redesign.

Le Retrofit (Le travail de colmatage) :
L'équipe a tenté de réparer les anciennes routines mathématiques qui fuient. Ils ont pris le code original, qui possédait des raccourcis dépendant du secret (comme un labyrinthe avec des portes cachées), et ont forcé le code à parcourir le même chemin à chaque fois. Ils ont fait cela en faisant en sorte que le code exécute chaque étape possible, même celles dont il n'avait pas besoin, et en utilisant des astuces « sans branchement » (branchless) pour masquer le chemin réellement emprunté. C'était comme forcer un coureur à faire le tour de chaque pièce d'une maison, peu importe où se trouve la sortie, afin qu'un observateur ne puisse pas savoir de quelle pièce il est sorti.

Le Redesign (La nouvelle construction) :
L'alternative consistait à jeter l'ancien algorithme mathématique et à le remplacer par un tout nouvel algorithme (appelé safegcd) qui a été construit de toutes pièces pour ne posséder aucun raccourci. Ce nouveau labyrinthe possède un chemin fixe qui semble exactement le même, quel que soit le secret.

Les Résultats Choc : Vitesse et Fuites Sournoises

Les chercheurs ont mesuré deux choses : le coût (en temps et en énergie) de l'exécution de ces défenses, et s'ils arrêtaient réellement le voleur.

1. Le Coût du Colmatage
Les résultats sont stupéfiants. Le « Redesign » est incroyablement efficace. Cependant, le « Retrofit » est un désastre en termes de vitesse.

• Pour la routine GCD, le retrofit était 192 fois plus lent que le redesign.
• Pour l'inversion modulaire, le retrofit était 532 fois plus lent.
• Pour donner une perspective, sur le matériel testé, la routine redessinée prenait des millisecondes pour s'exécuter. La routine rétrofitée ? Elle prenait des secondes. Plus précisément, le GCD rétrofité prenait environ 4,5 secondes par appel, et l'inversion modulaire un énorme 25 secondes. Pour un appareil qui doit déverrouiller une porte ou signer un message instantanément, attendre 25 secondes est pratiquement inutile. Le redesign n'était pas seulement meilleur ; c'était la seule option rendant l'appareil utilisable.

2. La Fuite « Fantôme »
C'est ici que l'histoire devient vraiment intéressante. Les chercheurs pensaient que le Retrofit était un succès. Lorsqu'ils ont mesuré le temps total d'exécution, le Retrofit semblait parfait. Le temps variait de moins de 2 % entre différents secrets, ce qui est généralement considéré comme « sûr ».

Mais ensuite, ils ont utilisé un outil ultra-précis pour vérifier les instructions exactes exécutées par l'ordinateur, étape par étape. Ils ont découvert une « fuite fantôme ».

• Dans le Retrofit, il y avait une petite boucle cachée à la toute fin du processus mathématique. Pour la plupart des entrées, elle s'exécutait un nombre fixe de fois. Mais pour un secret spécifique, elle s'exécutait une fois de plus.
• Cette étape supplémentaire n'ajoutait que quelques dizaines de cycles d'horloge au temps total. Comme le temps total était immense (des milliards de cycles), cette infime différence était totalement invisible pour les tests de temps standards. C'était comme si un voleur remarquait un seul clin d'œil supplémentaire dans un film de 25 secondes.
• L'attaquant M-Step, qui observe chaque étape, aurait vu ce clin d'œil supplémentaire et aurait su exactement quel était le secret.
• Les chercheurs ont dû revenir en arrière pour corriger cette petite boucle, en la remplaçant par une séquence fixe, afin de véritablement fermer la porte.

Le Verdict : Construisez du Neuf, Ne Colmatez Pas

L'article conclut par un message clair pour les ingénieurs en sécurité : N'essayez pas de colmater ces types spécifiques de routines mathématiques.

1. Le Redesign est Roi : L'approche « constant-time-by-design » (temps constant par conception) est largement supérieure. Elle est environ deux ordres de grandeur (100 fois) plus rapide que d'essayer de colmater l'ancien code.
2. Les Tests de Temps Mentent : Vous ne pouvez pas faire confiance aux tests de temps standards pour vous dire si un patch est sûr. Un patch peut sembler parfait sur un chronomètre mais présenter une fuite minuscule et exploitable qu'un attaquant par « pas unique » pourra voir.
3. Vérifiez les Étapes, Pas l'Horloge : Pour être sûr qu'une défense fonctionne, vous devez vérifier la séquence exacte des instructions (le chemin emprunté), et non pas seulement le temps total écoulé.

Les chercheurs ont découvert que même après avoir corrigé la fuite fantôme, une infime variation de temps subsistait (environ 2 %). Cependant, ils ont prouvé qu'il ne s'agissait pas d'une fuite de secret, mais simplement du comportement du matériel lui-même qui réagissait légèrement différemment selon les nombres qu'il traitait, un « plancher matériel » que même le meilleur logiciel ne peut éliminer. Mais crucialement, le chemin emprunté par l'ordinateur était désormais identique à chaque fois, ce qui signifie que le voleur ne pouvait plus apprendre le secret en observant les étapes.

En bref : lorsqu'il s'agit de ces secrets mathématiques critiques, ne tentez pas de réparer l'ancienne maison. Démolissez-la et construisez-en une nouvelle qui a été conçue pour être sécurisée dès le départ. C'est plus rapide, plus sûr, et vous ne manquerez pas les petites fissures qu'un colmatage laisse derrière lui.