AUDIT CRYPTOGRAPHIQUE

CONTEXTE

Lab de sécurité matérielle : canal auxiliaire temporel sur cible STM32

RÔLE

Conception de l'attaque, instrumentation, méthodologie de mesure, rédaction

LIVRABLES

Outil de récupération Python, mise en route UART/JTAG, rapport de 15 pages, recommandations de durcissement

RÉSULTAT

Récupération complète du mot de passe par analyse temporelle sur médiane ; correctif : comparaison en temps constant

« Crappy Safe » n'est pas un nom trouvé pour faire joli sur un firmware vulnérable : c'est une description exacte. La routine de vérification du mot de passe comparait les caractères un à un et renvoyait un échec à l'instant précis où elle tombait sur une différence. Ce choix de conception transforme la routine d'authentification en instrument de mesure : interrogez-la avec un premier caractère faux, vous obtenez une réponse en T₁ millisecondes ; avec un premier caractère bon et un deuxième faux, vous obtenez T₂ > T₁. C'est l'écart de temps qui livre la clé. L'algorithme n'est jamais entamé : l'attaque se contente de lire ce que le matériel ne peut s'empêcher d'émettre.

UART pour dialoguer avec la cible, JTAG pour le flashage, avec un correctif nécessaire dès le départ sur l'identifiant JTAG de la puce clonée, que la chaîne d'outils refusait de reconnaître. La mesure s'appuyait sur la médiane de requêtes répétées : la médiane et non la moyenne, car les distributions temporelles sur du matériel embarqué n'ont rien de gaussien. Les routines d'interruption et la gigue d'horloge génèrent des valeurs aberrantes qui faussent la moyenne et noient le signal sous le plancher de bruit. Choisir le bon estimateur supposait de regarder d'abord à quoi ressemblait la distribution réelle. Cette étape manque à la plupart des tutoriels sur les canaux auxiliaires, et c'est en la sautant que les implémentations naïves de l'attaque échouent.

La récupération tourne en boucle : pour chaque position de caractère, parcourir les candidats possibles, envoyer une requête préfixée, relever N mesures de temps, en prendre la médiane et repérer le candidat le plus lent. C'est le bon. On passe alors à la position suivante et on recommence. Les niveaux de difficulté du lab ajoutaient du bruit et des tentatives de contre-mesures actives, ce qui obligeait à retoucher N et les seuils de détection, mais pas la méthode de fond. Celle-ci tient parce que la vulnérabilité est structurelle : ajouter du bruit ne rend pas une comparaison à sortie anticipée constante en temps. Le bruit pèse autant sur les deux candidats, et l'ordre relatif, lui, demeure.

Le correctif tient en une comparaison de chaînes en temps constant : trois lignes de code, présentes dans n'importe quelle bibliothèque standard. Le rapport de quinze pages, sous Word et LaTeX, retrace tout le parcours expérimental : les mesures concluantes, celles qu'il a fallu refaire, et les choix de paramètres qui ont mis au jour la physique sous-jacente justement quand ils étaient mauvais. Les recommandations de durcissement couvrent la comparaison en temps constant, la limitation du débit d'authentification, le défi-réponse à base de nonce et l'ajout d'un watchdog contre l'injection de fautes. Dire ce qu'il faut corriger ne sert à rien si le rapport n'explique pas aussi pourquoi l'implémentation intuitive était fausse : sans cela, le développeur suivant referait le même choix pour les mêmes raisons.