Contexte technique

Le RP2350 de Raspberry Pi intègre un Arm Cortex‑M33 ou un cœur RISC‑V Hazard3 selectable à l’amorçage, ainsi que plusieurs protections matérielles : démarrage sécurisé, TrustZone Armv8‑M, et un drapeau permanent CRIT1.DEBUG_DISABLE qui désactive les Memory Access Ports (Mem‑AP) des deux cœurs. Les bits de configuration sont stockés dans une mémoire OTP de 128 octets, organisée en pages de 128 octets protégées par deux lignes de verrouillage (PAGEn_LOCK0 et PAGEn_LOCK1). Chaque bit d’OTP ne peut passer de 0 à 1 qu’une seule fois, et les champs critiques sont encodés avec un vote trois‑sur‑huit pour résister aux altérations.

Le registre DEBUGEN, mappé en mémoire, possède cinq bits fonctionnels : PROC0, PROC0_SECURE, PROC1, PROC1_SECURE et MISC. La documentation indique que DEBUG_DISABLE « peut être entièrement contourné en réglant tous les bits de ce registre », créant ainsi une porte d’entrée potentielle pour un attaquant disposant d’un accès physique.

Méthode d’injection et localisation

Les chercheurs ont d’abord décapsulé le RP2350 afin que la lumière infrarouge atteigne les transistors depuis le substrat. Cette opération a nécessité le retrait du cadre de broches et la restauration du plan de masse par un fil de cuivre, comme le montre la photo du dispositif monté sur la plateforme Scaffold. Ensuite, ils ont employé la microscopie d’émission de photons pour identifier le point exact où le registre DEBUGEN influence les lignes de contrôle des Mem‑AP. La technique a permis de réduire la zone de recherche du laser à deux positions adjacentes, limitant ainsi le nombre de tirs nécessaires.

// Exemple de valeur de DEBUGEN pour réactiver le debug sécurisé
DEBUGEN = 0b00000101; // PROC0 + PROC0_SECURE activés

Des impulsions laser ciblées sur ces deux positions ont induit des faults de type « bit‑flip », modifiant les bits PROC0_SECURE et PROC1_SECURE de DEBUGEN. Cette modification a réactivé les Mem‑AP en mode Secure, même si CRIT1.DEBUG_DISABLE restait à 1. L’attaque a ensuite utilisé le port SW‑DP pour établir une session de debug, lire la mémoire sécurisée et, après un « rescue reset », extraire le secret de 128 bits stocké dans la page OTP 1.

Analyse des impacts et limites

Le scénario démontre que la chaîne de protection du RP2350 possède une faiblesse logique : la possibilité de contourner un drapeau permanent via un registre logiciel. La réussite de l’injection dépend de plusieurs facteurs quantifiables : un équipement de laboratoire d’environ 250 000 $, une préparation destructive du dispositif, et une localisation précise rendue possible uniquement par la microscopie d’émission de photons. Sans ces moyens, la probabilité de toucher le registre cible reste négligeable.

Du point de vue de la sécurité, l’attaque ne compromet pas la confidentialité du code firmware tant que le secret OTP reste protégé par le verrouillage runtime appliqué après le démarrage. Cependant, la récupération du secret OTP 1 montre que, après un redémarrage contrôlé, le verrouillage runtime disparaît, laissant la donnée exposée tant que le registre DEBUGEN reste altéré. Cette limitation souligne l’importance de renforcer la séparation entre les contrôles matériels permanents et les registres accessibles en mode Secure.

En pratique, la mitigation la plus efficace consiste à éliminer le registre d’override ou à le rendre en lecture‑seule après le démarrage, de façon à empêcher toute modification par injection de fautes. Tant que le RP2350 restera disponible dans des environnements où un adversaire peut accéder physiquement au die, le vecteur décrit constitue une menace réaliste, bien que coûteuse.