Augmenter la sécurité à l’interface entre logiciel et matériel

Frédéric Tronel, Alessandro Palumbo et Lionel Hemmerlé, membres de l'équipe SUSHI sur le stand Inrua lors de l'European Cyber Week 2024 à Rennes

On les appelle les critères communs. Ils existent depuis l’an 2000. Ils constituent la norme ISO 15408. Leur rôle ? Servir de référentiel pour évaluer la sécurité des systèmes informatiques d’une façon impartiale. “Si vous êtes un industriel, vous souhaitez que votre produit soit reconnu comme offrant un certain niveau de sécurité. Parfois, c’est même obligatoire. Dans le domaine militaire par exemple. Pour cela, vous allez faire évaluer votre produit par un laboratoire indépendant, lui-même agréé par une agence nationale. Aux États-Unis, c’est la NSA et le NIST. En France, c’est l’ANSSI, Agence nationale de la sécurité des systèmes d'information. Quant aux laboratoires, ce sont principalement des entreprises privées^[1]. Ils mènent une activité commerciale qui se doit d’être la plus efficace et la moins coûteuse possible. Or, une évaluation, ça coûte cher. Il faut donc développer des outils pour permettre à ces acteurs d’évaluer plus facilement, notamment pour identifier des vulnérabilités. C’est à la fois un besoin économique des laboratoires et un besoin stratégique des États. Un de nos trois axes de recherche porte justement sur l’analyse de vulnérabilités. Soit pour identifier celles dont on connaît déjà les classes, soit pour en trouver de nouvelles,” résume Guillaume Hiet, responsable de SUSHI^[2].

Sur le campus de Rennes, cette nouvelle équipe-projet Inria associe CentraleSupélec, le CNRS et l'ENS-Rennes. Son centre d’intérêt : la sécurité dans les couches basses, à l’interface du logiciel et du matériel.

L’équipe est actuellement impliquée dans SecurEval. Coordonné par le CEA, il s’agit de l’un des 10 projets composant le PEPR Cybersécurité^[3],  un Programme et équipement prioritaire de recherche lancé dans le cadre du plan d’investissement France 2030.

Analyse de code binaire

“Dans ce projet, SUSHI contribue sur deux points. Le premier concerne l’analyse de code binaire, donc une application déjà compilée pour laquelle on ne dispose pas du code source. Le cas se présente assez peu pour l’instant. Car en principe, lors de l’évaluation sur les critères communs, l’éditeur vient avec son code source.”

Cependant, il existe un autre schéma : “le CSPN, Certification de sécurité de premier niveau. Actuellement, il est uniquement français mais il existe un accord de reconnaissance mutuelle avec l’Allemagne, qui a mis en place un dispositif un peu similaire.” La différence par rapport aux critères communs ? “Plus léger, donc moins cher. Et surtout plus ‘boîte noire’. On prend le produit fini et on l’évalue. Donc si c’est un logiciel, on doit pouvoir évaluer non plus le code source, mais le code binaire.” Une autre paire de manches...

Binsec

“Pour effectuer cette analyse de code binaire, le CEA développe un outil spécifique appelé Binsec. Nous travaillons ensemble pour l’améliorer. Par ailleurs, nous envisageons une collaboration avec Dartmouth College sur un autre outil du même type.”

Deuxième axe de recherche : “les méthodes formelles pour prouver les mécanismes de sécurité sur tout ou partie du matériel. Nous avons commencé ces travaux à travers un contrat de collaboration entre Inria et l’ANSII. Nous allons les poursuivre dans le cadre du PEPR. Cela va se traduire par des développements pouvant être réutilisés par les industriels souhaitant proposer du matériel prouvé formellement.”

Assistant de preuve Coq

Dans ce contexte, SUSHI s’appuie sur l’assistant de preuve Coq et travaille avec EPICURE, une équipe Inria spécialisée dans les méthodes formelles^[4]. “Sur ce sujet, nous souhaitons amorcer des collaborations avec des industriels qui veulent monter en niveau dans les critères communs. Le mieux, pour garantir que le mécanisme de sécurité fonctionne, c’est d’effectuer une preuve formelle. Naturellement, cela ne concerne pas tous les produits, mais ceux pour lesquels le besoin de sécurité est particulièrement fort, par exemple, ceux implémentant des mécanismes cryptographiques.”

Troisième axe de recherche : la détection et la réaction aux intrusions. “Vous exécutez une application sur une plateforme qui est vulnérable. Au minimum, vous voulez garantir que si un attaquant essaye d’exploiter ces vulnérabilités, vous allez détecter automatiquement l’attaque. Et vous aimeriez aussi pouvoir y réagir automatiquement. Si un ransomware se met à chiffrer des fichiers, au minimum, vous voudriez que le système vous les restaure. Donc qu’il revienne au dernier point de sauvegarde. C’est nécessaire, mais pas suffisant. Pourquoi ? Parce qu’avec cette restauration, le mécanisme vous ramène dans le passé, à un moment où le système était vulnérable. Donc l’attaquant peut rejouer. Par conséquent, le mécanisme doit aussi appliquer des contre-mesures pour que l’attaque ne se reproduise pas.”

Sécuriser la machine individuelle

Beaucoup de travaux dans ce domaine concernent les grands systèmes d’information comme les réseaux de serveurs. Les scientifiques de SUSHI, eux, se positionnent plutôt au niveau de la machine individuelle. Un simple ordinateur par exemple. Avec deux centres d’intérêt.

Pour ce faire, les chercheurs vont tirer parti d’extensions de virtualisation qui existent sur les ordinateurs actuels. “Le système normal de l’utilisateur tourne déjà en réalité dans une machine virtuelle. À côté, mais à l’extérieur, il y a ce que l’on appelle un hyperviseur chargé de répartir les ressources. Et c’est dans cet hyperviseur que nous allons installer notre système de surveillance. Donc si un virus se propage dans la machine virtuelle, il ne pourra pas remonter jusqu’à notre gardien.”

Un gardien sur processeur dédié

Deuxième problème : “quand on colocalise le système de surveillance avec le système à surveiller, on prélève de la ressource sur ce dernier. Ce qui pénalise sa performance. Notre objectif, c’est d’être plus efficace.” Comment ? “En installant le système de surveillance sur un processeur dédié et en préservant ainsi les ressources du processeur principal.”

Ces travaux se déroulent dans le cadre de TrustGW^[5], un projet financé par l’Agence nationale de la recherche. “Nous avons aussi collaboré avec HPLabs qui s’intéresse beaucoup à ces sujets, comme d’autres industriels, d’ailleurs.”

Implantée à Rennes, l’équipe SUSHI évolue au cœur du Pôle d’excellence cyber (PEC) où se côtoient de nombreux acteurs académiques, industriels ou étatiques de la cybersécurité et de la cyberdéfense. “La présence de cet écosystème nous a permis de tisser beaucoup de liens localement d’une façon assez naturelle. Ce qui nous amène à travailler surtout au niveau national. Mais nous aimerions désormais sortir de cette zone de confort pour développer des collaborations à l’étranger et aussi participer à des projets européens.”

^[1]En France, ces laboratoires s’appellent des CESTI : Centre d’évaluation de la sécurité des technologies de l’information. Ils sont au nombre de cinq : Amossys, Oppida, Thales/Cnes/ CEA-Leti, Serma Safety & Security.

^[2]SUSHI est une équipe-projet Inria, CentraleSupélec, CNRS et ENS-Rennes, de l'Irisa. Ses membres permanents sont : Guillaume Hiet, Alessandro Palumbo, Frédéric Tronel, Thomas Rokicki, Yaëlle Vinçont, Pierre Wilke et Louis Rilling (ingénieur de recherche DGA-MI).

^[3]Piloté par le CEA, le CNRS et Inria, le PEPR Cybersécurité rassemble 200 chercheurs et chercheuses issus de 26 établissements académiques. Il dispose d’un budget de 65 millions d’euros.

^[4]Épicure est une équipe-projet Inria, Université de Rennes, ENS Rennes et CNRS, commune à l’Irisa.

^[5]Le projet TrustGW associe le Lab-STICC, l'Irisa et l'IETR.