State Authenticity under Multiple Bus Masters: A Non-Secure DMA Gap and Mitigation for TrustZone-M Proofs of Executio

Imaginez un monde où de minuscules et peu coûteux ordinateurs sont éparpillés partout : à l'intérieur de votre thermostat intelligent, de votre bracelet connecté et même dans les capteurs d'une usine. Ces petits appareils sont censés être des rapporteurs honnêtes, renvoyant des données comme des relevés de température ou des comptages de mouvements. Mais et si un pirate informatique prenait le contrôle de l'un de ces appareils et commençait à mentir, injectant de fausses données dans une immense base de données dans le cloud ? Pour empêcher cela, nous utilisons une « preuve d'exécution » numérique. Considérez cela comme un notaire pour les ordinateurs : l'appareil signe un reçu disant : « Je promets avoir exécuté ce problème mathématique spécifique exactement comme demandé, sans que personne ne vienne modifier les chiffres. »

Pour que cela fonctionne, l'appareil a besoin de deux choses : un moyen sécurisé de prouver qu'il a exécuté le bon code, et un moyen de prouver que les données qu'il a utilisées (l'« état ») n'ont pas été altérées. Le document dont nous discutons examine une version spécifique et de haute technologie de ce système de preuve, appelée TrustZone-M, qui est intégrée dans de nombreuses micropuces modernes. C'est comme un coffre-fort ultra-sécurisé à l'intérieur de la puce qui sépare les tâches « de confiance » des tâches « non sécurisées ». La grande question est la suivante : si un pirate s'introduit du côté « non sécurisé », peut-il modifier discrètement les données pendant que l'ordinateur effectue ses calculs, trompant ainsi le système pour lui faire signer un faux reçu ? Cette étude examine si les règles actuelles du coffre-fort sont assez solides pour arrêter un assistant furtif et invisible capable d'écrire des données sans que l'ordinateur principal ne s'en aperçoive.

---

La plume invisible : Comment un hacker « fantôme » a trompé une puce sécurisée

Dans le jeu à enjeux élevés de la sécurité embarquée, des chercheurs ont récemment proposé un schéma ingénieux appelé SLAPP (Stateful Proofs of Execution - Preuves d'exécution avec état). Imaginez SLAPP comme un bibliothécaire très strict qui veut vérifier qu'un étudiant (le dispositif) a résolu correctement un problème de mathématiques. Le bibliothécaire vérifie deux choses : d'abord, que l'étudiant a utilisé le bon manuel (le code), et deuxièmement, que l'étudiant n'a pas triché en modifiant les chiffres dans son cahier (l'état) pendant la résolution du problème.

La logique du bibliothécaire était simple et semblait infaillible : « Si l'étudiant essaie de modifier les chiffres dans son cahier, il doit d'abord ouvrir le manuel pour trouver les instructions sur la façon de le faire. Or, comme nous disposons d'un scanner magique qui surveille le manuel, tout changement dans les instructions serait immédiatement détecté. Par conséquent, si le manuel semble parfait, les chiffres dans le cahier doivent l'être aussi. »

Ce document tire cependant le rideau pour révéler une faille dans cette logique. Les chercheurs ont découvert que l'« étudiant » n'est pas le seul capable d'écrire dans le cahier. Il existe un second écrivain invisible : un contrôleur DMA (Direct Memory Access).

L'écrivain « Fantôme »

Pour comprendre le DMA, imaginez le processeur principal de l'ordinateur (le CPU) comme un chef cuisinier très occupé qui émince des légumes. Le chef est le seul autorisé à toucher la planche à découper (la mémoire) dans la cuisine. Le chef est surveillé par une caméra de sécurité (l'isolation TrustZone-M) qui garantit que personne d'autre ne puisse toucher la planche.

Mais attendez ! Un bras robotique (le contrôleur DMA) est assis dans la cuisine. Ce robot est programmé pour déplacer automatiquement les ingrédients du réfrigérateur vers la planche à découper. La caméra de sécurité ne surveille que les mains du chef. Elle ne sait pas que le robot existe. Le robot peut se pencher, saisir un sac de farine et le déverser sur la planche à découter pendant que le chef est occupé à émincer. Le chef ne voit jamais le robot, et la caméra de sécurité ne cille pas parce que les mains du chef n'ont pas bougé.

Dans le monde du schéma de sécurité SLAPP, le « robot » est le contrôleur DMA. Les chercheurs ont découvert que le système de sécurité ne surveillait que le chef (le CPU). Il supposait que si le livre de recettes (la mémoire du programme) n'était pas modifié, personne ne pouvait changer les ingrédients (l'état). Mais le robot pouvait changer les ingrédients sans toucher au livre de recettes.

L'attaque : Un empoisonnement silencieux

Les chercheurs ont mis en place un test sur une puce réelle (un microcontrôleur STM32L5) pour voir si ce rédacteur « fantôme » pouvait réellement briser le système. Ils ont créé un scénario où un hacker, ayant déjà pris le contrôle de la partie « non sécurisée » de la puce, utilisait le robot DMA pour remplacer un nombre légitime par un faux, juste au milieu du calcul.

Voici comment le tour de passe-passe s'est déroulé :

1. La Vérification : La partie sécurisée de la puce a vérifié le cahier et a vu que les chiffres étaient propres. Elle a donné son feu vert.
2. L'Échange : Immédiatement après la vérification, mais avant que le résultat final ne soit signé, le robot DMA est intervenu pour remplacer le nombre par une valeur « empoisonnée ».
3. La Signature : La puce a terminé le calcul en utilisant le nombre empoisonné et a signé le reçu.
4. Le Résultat : La caméra de sécurité a regardé le livre de recettes, a vu qu'il était intact, et a accepté le reçu comme valide.

Le résultat était une « preuve d'exécution » mathématiquement valide, mais factuellement mensongère. Le système certifiait un résultat basé sur des données qui avaient été altérées, alors même que l'ordinateur principal pensait que tout allait bien.

Pourquoi les défenses habituelles ont échoué

Les chercheurs ont ensuite demandé : « Pourquoi la sécurité intégrée de la puce n'a-t-elle pas arrêté cela ? » Ils ont testé trois défenses standards, et chacune a échoué pour une raison différente et curieuse :

1. La tentative de « Verrouiller le Robot » : Ils ont essayé de dire au système de sécurité de verrouiller le bras du robot. Mais le système a répondu : « Je ne contrôle pas les robots ; je ne contrôle que le chef. » La barrière de sécurité ne s'appliquait tout simplement pas au robot.
2. La tentative de « Verrouiller la Table » : Ils ont essayé de verrouiller la planche à découper pour que personne ne puisse la toucher. Mais c'était trop strict ! Le chef devait aussi écrire sur la planche. S'ils verrouillaient la planche, le chef ne pourrait plus faire son travail, et tout le système s'arrêterait.
3. La tentative de « l'Alarme » : Ils ont essayé de configurer une alarme qui retentirait si le robot touchait la planche. Mais l'alarme ne sonne que si quelqu'un enfreint une règle. Comme le robot était autorisé à toucher la planche (c'était juste le mauvais genre de contact pour cette règle de sécurité spécifique), l'alarme est restée silencieuse.

La Solution : Dompter le Robot

La solution n'était pas de construire un mur plus grand ou une alarme plus forte. Il s'agissait de donner au robot son propre badge de sécurité. Les chercheurs ont découvert que le robot (le contrôleur DMA) possédait en fait un interrupteur caché à l'intérieur, qui pouvait être actionné par le chef sécurisé.

En actionnant cet interrupteur, le monde sécurisé pouvait dire : « Ce bras robotique spécifique est désormais sous mon contrôle. Si le hacker essaie de lui donner des ordres, il les ignorera et lèvera un drapeau rouge. »

Cette correction était étonnamment peu coûteuse et facile. Elle ne ralentissait pas le chef et ne nécessitait pas de nouveau matériel. Les chercheurs l'ont testée en sécurisant tous les bras robotiques de la puce. Lorsqu'ils ont tenté l'attaque à nouveau, le robot a refusé de bouger, l'alarme a retenti, et le faux reçu a été rejeté.

La grande leçon

La leçon la plus importante de ce document ne concerne pas seulement une puce spécifique ou une technique de hacker particulière. C'est une leçon sur notre façon de concevoir la sécurité.

Pendant longtemps, les concepteurs de sécurité ont supposé que si l'on protégeait le cerveau principal (le CPU), on protégeait tout le reste. Ce document prouve que sur les puces modernes, il existe d'autres « mains » qui plongent dans la mémoire sans que le cerveau ne les voie. Si vous voulez faire confiance aux données d'un ordinateur, vous ne pouvez pas seulement surveiller le cerveau ; vous devez surveiller chaque main capable de toucher les données.

Les chercheurs ont montré que le système SLAPP, tel qu'il a été publié, présentait une faille dans sa logique car il avait oublié les « mains robotiques ». Ils n'ont pas seulement trouvé la faille ; ils ont montré exactement comment la colmater avec une correction simple et légère. C'est un rappel que, dans le monde des petits ordinateurs, les hackers les plus dangereux ne sont peut-être pas ceux qui tapent sur un clavier, mais les robots invisibles travaillant en arrière-plan, attendant que quelqu'un oublie de vérifier leur carte d'identité.