TrustZone sur Cortex-M : isolation, TF-M et ce que PSA garantit vraiment
TrustZone sur Cortex-M porte le même nom que sur Cortex-A, mais ce n'est pas la même technologie. Sur Cortex-A, l'isolation repose sur un bit d'état du processeur et un moniteur logiciel qui arbitre les transitions. Sur Cortex-M, elle est spatiale : chaque adresse mémoire appartient statiquement à un monde, et le processeur bascule en franchissant la frontière. Confondre les deux mène à des architectures qui ne tiennent pas.
Comment l'attribution mémoire fonctionne
Deux unités décident à quel monde appartient une adresse.
L'IDAU, implementation defined attribution unit, est câblée par le fabricant du silicium. Elle découpe l'espace d'adressage en régions prédéfinies, et vous ne pouvez pas la modifier.
La SAU, security attribution unit, est programmable, avec typiquement 4 ou 8 régions. Elle affine ce que l'IDAU a défini.
La règle de combinaison est celle qui surprend : le résultat le plus restrictif l'emporte. La SAU ne peut pas rendre non sécurisée une région que l'IDAU déclare sécurisée. Beaucoup de temps se perd à tenter une cartographie mémoire que le silicium interdit, avant de lire attentivement la documentation de l'IDAU.
Chaque adresse tombe dans l'un de trois états : sécurisé, non sécurisé, ou non sécurisé appelable. Ce troisième état est la clé du mécanisme.
Les transitions, et l'instruction SG
Le code non sécurisé ne peut pas sauter n'importe où dans le monde sécurisé. Il ne peut entrer que dans une région marquée NSC, non-secure callable, et uniquement sur une instruction SG, secure gateway. Toute autre tentative déclenche une faute de sécurité.
En pratique, la région NSC ne contient que des vestibules : une instruction SG, puis un branchement vers la vraie fonction sécurisée. Le compilateur les génère à partir des attributs cmse_nonsecure_entry, et l'éditeur de liens produit une bibliothèque d'import que le projet non sécurisé utilise pour connaître les points d'entrée.
Le retour se fait par BXNS ou BLXNS, avec un point souvent négligé : les registres du cœur sont automatiquement effacés au retour vers le monde non sécurisé, pour éviter la fuite de secrets. Mais cela ne concerne que les registres. Tout ce que votre code sécurisé a laissé dans une pile ou un tampon partagé reste lisible.
Le coût réel d'un appel sécurisé
Une transition n'est pas gratuite. Comptez, ordre de grandeur sur un Cortex-M33 :
| Opération | Coût typique |
|---|---|
| Appel de fonction ordinaire | quelques cycles |
| Transition non sécurisé vers sécurisé | 20 à 50 cycles |
| Appel de service TF-M complet | plusieurs centaines à quelques milliers de cycles |
Les valeurs chiffrées de cette section sont des ordres de grandeur observés, pas des spécifications. Elles dépendent du silicium, du compilateur et de la configuration. Mesurez les vôtres avant de dimensionner un produit sur ces bases.
L'écart entre les deux dernières lignes vient de ce que TF-M ajoute par-dessus le mécanisme matériel : validation des pointeurs fournis par l'appelant, changement de contexte de partition, sérialisation des paramètres.
La conséquence de conception est nette : on ne franchit pas la frontière dans une boucle. Une architecture qui appelle un service sécurisé à chaque échantillon d'un flux à 10 kilohertz s'effondre. Le schéma qui fonctionne est de faire traverser des blocs, pas des octets, et de garder le traitement volumineux du même côté que ses données.
Ce que TF-M apporte, et ce qu'il coûte
Trusted Firmware-M est l'implémentation de référence du monde sécurisé. Il fournit trois services principaux : stockage protégé, stockage interne fiable et cryptographie, plus l'attestation initiale.
Son intérêt n'est pas seulement d'éviter de réécrire ces services. C'est le modèle de partitions isolées : chaque service tourne dans son propre contexte, avec sa pile, et un dépassement dans l'un ne compromet pas les autres. On distingue trois niveaux d'isolation, du plus simple, où sécurisé et non sécurisé sont séparés, au plus strict, où chaque partition sécurisée est isolée des autres.
Le coût est réel : comptez plusieurs dizaines de kilooctets de flash et de RAM pour TF-M seul, selon les services activés et le niveau d'isolation. La seule mesure fiable est celle de votre configuration, la documentation TF-M détaillant les options qui pèsent le plus. Sur un microcontrôleur à 256 kilooctets, ce n'est pas une décision anodine.
Ce que PSA Certified garantit, et ce qu'il ne garantit pas
La certification PSA se décline en niveaux, et la confusion sur leur périmètre est fréquente.
Niveau 1 est une auto-évaluation par questionnaire, examinée par un laboratoire. Elle atteste que les exigences ont été considérées, pas qu'une attaque a été tentée.
Niveau 2 ajoute une évaluation en laboratoire résistant aux attaques logicielles évoluées, sur une durée limitée.
Niveau 3 couvre en plus les attaques matérielles : injection de fautes, analyse de consommation.
Le point à retenir : PSA certifie une plateforme, pas votre produit. Un microcontrôleur PSA niveau 2 avec TF-M ne rend pas votre application conforme si vous stockez une clé en clair dans le monde non sécurisé. La certification déplace la frontière de confiance, elle ne l'élimine pas.
Les erreurs d'architecture les plus fréquentes
Mettre trop de code dans le monde sécurisé. Chaque ligne y devient de la surface d'attaque privilégiée, et la revue de code doit y être bien plus stricte. Le monde sécurisé doit rester petit et auditable.
Faire confiance aux pointeurs venus du monde non sécurisé. Un service sécurisé qui reçoit une adresse de tampon doit vérifier qu'elle appartient bien au monde non sécurisé et que la plage entière est accessible. Les instructions TT et les fonctions cmse_check_address_range existent pour ça. Sans cette vérification, l'appelant fait lire ou écrire n'importe quelle adresse sécurisée par le code sécurisé lui-même.
Oublier que les périphériques ont aussi une attribution. Un contrôleur DMA programmé depuis le monde non sécurisé peut, si le silicium ne le filtre pas, lire de la mémoire sécurisée. La protection dépend d'un filtre de bus côté périphérique, pas de TrustZone seul.
Références
- Arm, TrustZone for Cortex-M, attribution SAU et IDAU, instructions
SG,BXNS - Arm, Armv8-M Security Extensions, modèle d'états et transitions
- Trusted Firmware-M, services, niveaux d'isolation et empreinte
- PSA Certified, périmètre des niveaux 1, 2 et 3
- Arm, CMSE, ARM C Language Extensions,
cmse_nonsecure_entryetcmse_check_address_range
Pour aller plus loin
Ces mécanismes deviennent tangibles une fois qu'on a programmé une SAU, tracé une faute de sécurité sur une transition mal formée, et mesuré le coût réel d'un appel de service. C'est le contenu de nos cours sur la sécurité avancée des systèmes embarqués et sur l'architecture ARM Cortex-M.