Mieux sécuriser les cœurs de processeur contre les cyberattaques

65 millions d’euros. 200 chercheurs. 26 établissements académiques. Le PEPR Cybersécurité est un Programme et équipement prioritaire de recherche lancé dans le cadre du plan d’investissement France 2030. Piloté par le CEA, le CNRS et Inria, il décline 10 projets de recherche fondamentale au service de la filière industrielle et des acteurs étatiques.

Pour ces travaux, les scientifiques vont s’appuyer sur RISC-V. Ronan Lashermes, scientifique au Laboratoire de Haute Sécurité (LHS)^[1] précise : 

Et cela, d’autant plus qu’il est soutenu non seulement par une importante communauté de recherche, dont Inria fait partie, mais aussi par de très grosses entreprises. C’est le cas de Google et Intel aux États-Unis. Ou encore Thales, en France.

Attaques par injection de fautes

Le projet Arsene^[2] va porter sur la sécurisation de deux familles de processeurs RISC-V. Le premier est un 32 bits. « C’est l’équivalent d’un microcontrôleur. Le genre de petit processeur très simple que l’on trouve dans les appareils électro-ménagers ou les objets connectés. Ils sont difficiles à protéger contre les attaques physiques car l’attaquant peut dérober l’objet et le soumettre ensuite à des attaques par injection de fautes. Il faut donc que ce processeur soit tolérant aux fautes. Mais il faut aussi prouver que cette protection fonctionne. Cela requiert l’utilisation de méthodes formelles appliquées au matériel. » Cette partie fera intervenir des chercheurs de Taran^[3], une équipe rennaise travaillant sur l’optimisation et la résilience de microarchitectures spécialisées. Ces travaux seront coordonnés pas Simon Rokicki.

Les scientifiques de Taran ont développé aussi un savoir-faire en DBT (Dynamic Binary Translation). Il s’agit d’une technique de traduction dynamique qui prend un jeu d’instructions externe et le convertit en un jeu d’instructions optimisées pour des accélérateurs matériels. Dans le contexte du projet, l’idée est de concevoir cette fois-ci une traduction vers un jeu d’exécutions possédant des propriétés de sécurité particulières. Ainsi, certaines exécutions critiques seraient effectuées plusieurs fois pour se prémunir contre les fautes.

Spectre : une vulnérabilité conceptuelle

Le deuxième processeur est un processeur applicatif 64 bits comme on peut en trouver dans les ordinateurs de bureau ou les téléphones mobiles. Il s’agira en l’occurrence d’un démonstrateur sur un circuit reprogrammable de type FPGA.

Ici, les chercheurs vont s’intéresser plus particulièrement à Spectre : une vulnérabilité conceptuelle présente dans les processeurs actuels. « Ces processeurs sont engagés dans une course à la performance. Pour aller toujours plus vite, ils recourent à ce que l’on appelle de l’exécution spéculative. Lorsque le processeur doit faire un choix qui dépend d’une condition, cela peut prendre beaucoup de temps pour aller récupérer l’information de cette condition. Savoir si elle est vraie ou fausse. Notamment s’il attend les résultats d’une division longue à calculer ou bien encore une donnée qui se trouve loin en mémoire. Plutôt que d’attendre très longtemps, il va donc spéculer. Il va parier sur le résultat de ce branchement et continuer l’exécution sur une fenêtre de temps qui peut être assez longue : plusieurs centaines d’instructions. À la fin, si son pari se révèle bon, c’est tout bénéfice. Il a gagné beaucoup de temps. Mais si le pari est perdu, alors le processeur doit revenir en arrière et faire comme s’il n’avait jamais exécuté toutes ces instructions lors de l’exécution spéculative. »

Problème :« quand il revient en arrière, le processeur ne peut pas effacer toutes les traces laissées par l’exécution. Et c’est là que se trouve la vulnérabilité Spectre : un attaquant peut tenter d’exploiter l’information contenue dans ces traces. » Une des pistes pour atténuer le risque consiste à stopper cette exécution spéculative si on anticipe qu'elle va laisser des traces impliquant des secrets.

© Inria / TARAN

Mettre les développeurs dans la boucle

Dans la boucle de sécurité, les scientifiques veulent aussi inclure un acteur clé : le développeur. « Actuellement, celui-ci se heurte à un problème d’ergonomie de ses outils. Quand il développe en C, par exemple, ce langage n’a aucun moyen de lui dire : 'attention, telle variable est secrète et il faut l’utiliser de telle manière'. Nous voudrions donc donner au développeur les moyens d’avoir plus de contrôle sur ce qu’il fait pour que l’on puisse ensuite gérer au mieux la compilation. Nous souhaiterions aussi que le compilateur soit capable d’inférer automatiquement qu’une donnée est secrète pour générer les instructions en conséquence. » Cette partie des travaux sera menée par la deuxième équipe rennaise impliquée dans le projet. Il s’agit de Pacap^[4] qui réunit des spécialistes de l’architecture processeurs et de la compilation.

^[1] Le LHS est un laboratoire commun entre la région Bretagne, la DGA, l’Inria, CentraleSupelec et le CNRS au sein du Pôle d’excellence cyber (PEC).

^[2] Piloté par le CEA (LCYL, LFIM, LSCO), le consortium Arsene s’appuie sur environ 80 scientifiques provenant d’une vingtaine d’établissements : CNRS (Lab-STICC, LIRMM, LHC)), Inria (LHS, Taran, Pacap), IMT Mines Saint-Étienne (SAS, SSH), Université Grenoble Alpes (LCIS, TIMA, Verimag), Université Jean Monnet Saint-Etienne, Université de Rennes, UBO, UBS, Ensta Bretagne, TelecomParisTech, INP Grenoble, TelecomParisTech… Arsene est l’acronyme d’Architecture SEcurisées pour le Numérique Embarqué.

^[3] Taran est une équipe Inria, Université de Rennes et ENS Rennes, commune avec l’Irisa.

^[4] Pacap est une équipe-projet Inria et Université de Rennes, commune avec l’Irisa.