Isolation des IP sécurisées de la partie reconfigurable du SoC
Cette section présente une méthodologie d’isolation matérielle et logicielle des IP sécurisées de la partie reconfigurable d’un SoC complexe hétérogène embarquant la technologie ARM TrustZone. Cette méthodologie est composée de trois étapes et utilise une technique d’isolation matérielle et des configurations logicielles pour protéger les IP sécurisées et les régions sécurisées de la mémoire externe. La figure 48 donne un aperçu de l’isolation des IP sécurisées (encadrées en violet) dans la partie reconfigurable du SoC Dans cette méthodologie, les IP sécurisées à isoler doivent être des IP de confiance, c’està-dire que l’intégrateur doit avoir l’assurance qu’elles ne contiennent pas de vulnérabilité. Des certifications (à l’image de celles proposées pour les Trust Applications que l’on peut exécuter dans une TEE) pourraient être envisagées dans ce but. Cependant, aujourd’hui il n’existe pas de certifications pour cela et c’est avant tout un lien de confiance entre l’intégrateur et le concepteur de l’IP qui doit permettre de réduire les risques (c’est le cas si par exemple l’intégrateur et le concepteur de l’IP font partie de la même société). Dans le cas d’un SoC du type Xilinx Zynq, la méthode que nous proposons pour l’isolation des IP sécurisées de la partie reconfigurable est constituée des trois étapes suivantes :
Isolation physique et logique des IP sécurisées dans la partie reconfigurable du SoC
Dans cette étape, le concepteur doit utiliser la méthodologie d’isolation du flux de conception (Isolation Design Flow [78], IDF) de Xilinx qui permet à des IP indépendantes de fonctionner sur un seul FPGA avec une séparation logique et physique. L’IDF implémente et route les IP dans des zones isolées et entourées d’une « clôture » composée d’un ensemble d’éléments logiques configurables non configurés (sans fonction logique) dans lesquels aucun routage n’est présent (pas de connexions internes ni externes, pas de ligne de routage traversant les éléments logiques configurables en dehors des connexions aux entrées-sorties de l’IP isolée). L’IDF utilise également un outil indépendant de vérification des règles de conception (Design Rule Check, DRC en anglais), pour vérifier la clôture et les connexions avec la zone isolée.
Utilisation de deux interfaces maîtres de la partie processeur du SoC
Comme cela est représenté au centre de la figure 48, dans la partie processeur du SoC, deux interfaces vont contrôler les interfaces des IP sécurisées (connexions vertes sur la figure 48) et pour contrôler celles des IP non-sécurisées (connexions rouges sur la figure 48). Dans le cas du SoC Xilinx Zynq-7000, la partie processeur possède deux interfaces maîtres à usage général : l’interface AXI GP0 et l’interface AXI GP1. Ces deux interfaces peuvent être utilisées pour contrôler les interfaces esclaves des IP sécurisées et non sécurisées comme cela est présenté sur la figure 48. Sur cette figure, l’interface AXI GP1 est utilisé pour contrôler les IP sécurisées et l’interface AXI GP0 est utilisé pour contrôler les IP non sécurisées. Chacun de ces deux interfaces a une région de la mémoire externe qui lui est dédiée (la région mémoire GP1 pour l’interface AXI GP1 et la région mémoire GP0 pour l’interface AXI GP0 comme cela apparait sur la figure 48). De plus, le SoC Xilinx Zynq-7000 propose des registres de configuration liés à chacune des deux interfaces maîtres AXI GP1 et AXI GP0. Ces registres configurent la propagation de l’état de sécurité des requêtes de la partie processeur vers la partie reconfigurable du SoC. Par exemple, dans la figure 48, comme il contrôle les IP non sécurisées, l’interface AXI GP0 est configuré pour interdire la propagation de l’état de sécurité des requêtes de la partie processeur vers les IP sécurisées. Toute requête non-sécurisée destinée aux IP sécurisées (accès à la région mémoire GP1 (en vert dans la figure 48) de la mémoire externe dédiée à l’interface AXI GP1) est rejetée au niveau de l’interface AXI GP0, et une exception est alors déclenchée dans la partie processeur du SoC.
Limitation des accès aux régions sécurisées de la mémoire externe
Pour cette étape, le concepteur doit interdire aux interfaces maîtres des IP non-sécurisées d’accéder aux régions sécurisées de la mémoire externe. Dans le cas du SoC Xilinx Zynq-7000, la partie processeur possède deux interfaces esclaves AXI GP (interface esclave GP0 et interface esclave GP1), quatre interfaces haute performance (HP) et une interface ACP pour la cohérence de la mémoire cache (dont nous avons montré l’exploitation malicieuse dans le chapitre précédant). Ces interfaces permettent théoriquement aux IP de la partie reconfigurable du SoC un accès direct à l’intégralité de la mémoire externe. Cependant, il est possible de limiter cet accès à des régions spécifiques. Pour cela, les interfaces esclaves AXI GP et HP disponibles doivent être scindées en deux groupes distinct pour être connectés aux interfaces maîtres des IP sécurisées (connexions vertes sur la figure 48) et non-sécurisées (connexions rouges sur la figure 48) de la partie reconfigurable du SoC. Pour limiter la possibilité de réaliser les attaques ciblant la mémoire cache (voir chapitre 4), l’utilisation de l’interface ACP doit être strictement limitée aux seules IP sécurisées de la partie reconfigurable du SoC. Pour le SoC Xilinx Zynq-7000 il existe des registres de configuration liés à chacune des interfaces esclaves AXI GP et HP. Ces registres contrôlent les accès aux régions sécurisées de la mémoire externe depuis la partie reconfigurable du SoC. Par exemple, dans le cas de la figure 48, les registres de contrôle des interfaces esclaves AXI GP et HP connectées aux IP non-sécurisées (connexions rouges dans la figure 48) doivent être configurés pour interdire aux interfaces maîtres des IP non-sécurisées d’accéder à la région mémoire sécurisée (région mémoire GP1 en vert dans la figure 48) de la mémoire externe. Cette configuration réduit les menaces que représente des attaques par accès directes DMA depuis la partie reconfigurable que nous avons présenté dans le chapitre 3 de ce manuscrit. Cette méthodologie en trois étapes permet aux concepteurs de renforcer la sécurité d’un SoC hétérogène complexe contre la majorité des attaques présentées dans ce manuscrit. Cependant, cela n’est pas suffisant, et des protections supplémentaires doivent être utilisées pour protéger le système contre les chevaux de Troie matériels insérés dans la partie reconfigurable du SoC. La suite de ce chapitre présente un système de vérification des règles de conception qui permet de vérifier les connexions entre les différents blocs du design.