Les techniques classiques de codage et d’authentification ont un coût en surface, temps et consommation d’énergie qui ne sont pas compatibles avec le domaine des NoCs. Nous proposons ici des techniques originales.
5.3.1 Garantir le trafic contre le déni de service
Une simple solution contre l’attaque de déni de bande passante consiste à utiliser des canaux virtuels (VCs)[20] pour séparer les communications sûres et non-sûres. Les canaux virtuels permettent de multiplexer plusieurs trafics sur un même canal physique. Chaque canal virtuel peut se voir affecter un niveau de priorité, ce qui permet d’avoir plusieurs classes de priorités de trafics.
Nous pouvons utiliser 2 canaux virtuels, un premier de haut niveau de priorité pour assurer les échanges sécurisés dans la zone sûre et un second canal virtuel de faible niveau de priorité et de classe de trafic de faible sécurité. La zone sécurisée est donc traversée par deux types de canaux virtuels et donne la priorité aux paquets évoluant sur le canal virtuel prioritaire (figure 5.2).
Si aucune technique TDMA (Time division multiplexing access) n’est disponible pour allouer des slots au trafic non sûre alors une intégration simple consiste à n’as-signer que le VC de faible priorité à la zone non sûre. Les communications entre les deux zones n’utilisent alors que le VC de faible priorité. Ainsi, les communications sécurisées de la zone sûre sont isolées des potentielles attaques de déni de service.
Cependant cette solution ne protège que du déni de bande passante et ne traite pas les droits d’accès.
5.3 les stratégies de protection 77
Fig. 5.2 – Séparation des trafics sur des canaux virtuels différents
5.3.2 Filtre multi-frontières
Trois frontières de sécurité peuvent être considérées entre les zones sûre et non sûre. Chacune peut être équipée d’une protection spécifique (figure 5.3). La première pro-tection est une vérification d’autorisation à l’accès aux interfaces du NoC. La seconde est un filtre de chemin inséré dans le réseau. La troisième protection est une vérifica-tion par la NI destinataire de l’identité de l’émetteur qui lui adresse un paquet. Ces trois frontières de sécurité sont expliquées dans les sections suivantes.
Fig. 5.3 – Trois frontières de sécurité
5.3.2.1 Frontière 1
Tout le NoC est dans la zone sécurisée. Certaines IPs sont aussi dans la zone sécu-risée parce qu’elles sont critiques, mais d’autres IPs sont elles dans la zone non sûre et doivent pouvoir n’accéder qu’à certaines informations dans des fenêtres de temps limitées. La figure 5.4 présente un exemple.
Les détails de notre NI sont montrés sur la figure 5.5. Les NIs contiennent de nombreux paramètres de configuration. Ces paramètres sont configurables au travers du NoC lui même. Nous distinguons les éléments suivants dans la NI :
– Un adaptateur de protocole pour communiquer de façon appropriée avec le pro-tocole du port de la NI connectée.
– Une table d’espace d’adressage mémoire qui spécifie les droit d’accès. De plus, elle permet de convertir l’adresse logique demandée en l’identité de l’IP cible.
78technique de codage des chemins pour la sécurité et la reconfiguration – Une table de chemins, fournissant les instructions de chemin nécessaires pour
atteindre une destination atteignable (autorisée). – Une table des slots de temps alloués pour le GT.
– Une instruction spécifiant la bande passante maximale pouvant être allouée au BE. Ceci permet de maintenir la bande passante d’une communication dans une limite spécifiée.
Fig.5.4 – Exemple de NoC entièrement dans la zone sûre
Fig. 5.5 – Network Interface
Le CCM délivre aux NIs des autorisations d’accès mémoire. Les NIs sont limitées par ces droits. Une NI doit solliciter le CCM pour demander une nouvelle autorisation. Le CCM peut retirer une autorisation.
Ceci nous prémunit des attaques de type déni de service, grâce à la limitation de la bande passante et nous permet de contrôler les droits d’accès.
5.3.2.2 Frontière 2
Seule une partie du NoC est dans la zone sécurisée. Dans ce cas, nous ne pouvons pas avoir confiance dans les NIs se trouvant dans la zone non sûre. Ainsi, ici, l’information
5.3 les stratégies de protection 79 qui sera vérifiée ne sera non pas l’adresse mémoire logique comme précédemment, mais le contenu du paquet. En effet, le champ d’instruction de chemin dans l’entête du paquet indique comment atteindre la destination, ce qui permet de déduire la destination et correspond donc à l’adresse logique globale précédente.
Des filtres appelés path filter sont insérés dans la zone sûre à la frontière avec la zone non sûre (figure 5.6).
Fig. 5.6 – Noc dans la zone sûre et non sûre
Dans ce cas, le CCM délivre des autorisations relatives à des chemins (et non des espaces mémoires logiques comme précédemment) aux path filters. Un path filter reçoit des paquets de la zone non sûre et n’autorise à pénétrer dans la zone sécurisée que ceux qui ont des instructions de chemin autorisées. Cette solution empêche un émetteur de la zone non sûre d’accéder à un destinataire auquel il n’est pas autorisé. De plus, cette vérification par les instructions de chemin nous prémuni des deadlock et livelock.
Un path filter ressemble à une NI, excepté qu’il n’est pas connecté à une IP et n’a donc pas d’adaptateur de protocole, et qu’il possède une table de chemins à la place de la table d’espace d’adressage mémoire (figure 5.7) En pratique, pour éviter de perdre du temps, le path filter peut être intégré dans le port du routeur de la zone sûre. Cela permet de procéder simultanément à la vérification du chemin et à l’étape de décodage.
5.3.2.3 Frontière 3
Hypothèse de cette étude : Nous proposons ici de faire les vérifications sur les infor-mations de la couche réseau. Ainsi, on ne sécurise pas une application vis à vis d’une autre mais assurons l’authentification d’un composant connecté au NoC afin de lui attribuer des droits d’accès avec les autres. Pour cela nous nous servons des instruc-tions de chemin comme des marques indiquant au récepteur le chemin emprunté par le paquet. L’intérêt de se servir des instructions, plutôt que de marques qui seraient ajoutées par les routeurs traversés, est que nous économisons de l’espace dans l’entête du paquet.
80technique de codage des chemins pour la sécurité et la reconfiguration
Fig. 5.7 – Le path filter
De cette façon, un composant destinataire peut vérifier l’identité de l’émetteur. Ainsi, l’accès à une mémoire sera autorisé depuis certains processeurs et certaines interfaces mais pas depuis d’autres.
Cette authentification du composant source pourrait être réalisée par un identifiant qui serait placé dans l’un des champs de l’entête du paquet lors de sa création dans la NI. Cet identifiant serait alors consulté à la réception afin de vérifier l’identité de l’émetteur. Seulement, cet identifiant pourrait être usurpé, pour permettre à un composant de se faire passer pour un autre.
Nous proposons ici de nous appuyer sur la couche transport pour plus de sécurité. Ainsi, nous utilisons une technique de codage des instructions de routage qui permet à un destinataire de remonter vers l’identité de l’émetteur. En effet, la seule information qui ne puisse être corrompue pour tenter d’usurper une identité est l’information de chemin pour atteindre la destination, à condition que celle-ci soit unique et dans l’hypothèse que l’intégrité du NoC est garantie bien entendu. Nous appelons cette technique SPA (pour Source Path Authentication)