Entretien : Clémentine Maurice

> Bonjour Clémentine, tu es une chercheuse en sécurité, spécialisée sur les attaques impliquant les interactions entre matériel et logiciel. Pourrais-tu nous présenter ton parcours et nous expliquer comment tu es arrivée à travailler sur ce sujet très pointu ?

Bonjour ! Depuis le lycée, je voulais travailler dans l’informatique, sans avoir une idée précise du domaine. J’ai d’abord fait l’INSA Rennes, une école d’ingénieurs, où je me suis spécialisée en informatique. En dernière année, j’ai souhaité me spécialiser en sécurité, et je me suis tournée vers le master recherche de Rennes pour avoir un double diplôme. Mon stage de recherche, sur le fingerprinting Wi-Fi m’a bien plu, et j’ai continué avec une thèse (CIFRE, c’est à dire en partie en entreprise, à Technicolor dans mon cas). Le sujet de thèse était assez ouvert - "sécurité du cloud computing" - et j’ai donc commencé à lire beaucoup d’articles pour trouver ce qui m’intéressait le plus. J’y ai notamment découvert les travaux parlant d’attaques par canaux auxiliaires sur les caches des processeurs. Ce sujet m’a totalement fasciné : ces attaques utilisent les effets de bord du matériel pour en dériver par exemple des clés secrètes, ou encore communiquer de manière furtive. À cette époque je n’avais d’ailleurs plus que de vagues souvenirs des cours d’architecture des ordinateurs de mes études, et il m’a fallu me replonger dedans. Je suis maintenant en postdoctorat en Autriche, à Graz University of Technology, où je continue mes recherches sur ce domaine.

> Tu travailles dans un laboratoire de recherches académique notamment à développer ce type d’attaques. De tes quelques années d’expérience en recherche académique, penses-tu que ce type de recherche publique, appliquée et offensive est en croissance ou que 

cela relève encore de l’exception par rapport aux recherches plus théoriques ?
Oui, je travaille notamment à développer ces attaques par canaux auxiliaires, pour en avoir une meilleure compréhension, et pour qu’on puisse trouver de bonnes contre-mesures, qui adressent les problèmes de fond. Je pense que la communauté académique a réalisé que la recherche appliquée et offensive était une étape nécessaire pour construire des systèmes sécurisés. Aujourd’hui, je ne pense pas que ce type de recherche soit une exception. C’est d’ailleurs une bonne nouvelle pour la recherche dans son ensemble : il y a des travaux de recherche théoriques et formels, et des travaux empiriques, qui peuvent aussi permettre de valider ou infirmer les travaux théoriques.

> Dans le même ordre d’idée, penses-tu que la mise à disposition d’implémentation technique (code) pour étayer les papiers de recherche sont reconnues et valorisées dans le monde académique ? Et selon toi, est-ce que ces implémentations sont nécessaires et doivent-elles être mises à disposition sous licences libres ?

Je pense que la mise à disposition de code complémentant les articles est de plus en plus valorisée dans le monde académique - au moins dans le domaine de la sécurité. Certains articles mentionnent par exemple des liens vers le code, et certaines conférences encouragent la soumission de code. J’ai aussi récemment vu l’initiative FindResearch [1] par des chercheurs, qui devrait permettre à terme de recenser le code associé aux articles publiés. Je suis très partisane de ce genre d’initiatives, que je trouve absolument nécessaires. Le principe même de la recherche scientifique et de la méthode scientifique est basé sur les expérimentations, et la validation ou infirmation des hypothèses de départ face aux résultats. Pour qu’on puisse être certain qu’un résultat est valide, il est donc très important que d’autres chercheurs puisse le répliquer. En informatique, on a la chance de ne pas nécessairement avoir besoin de matériel coûteux pour répliquer des expériences (bien que certaines expériences puissent nécessiter beaucoup de puissance de calcul). En théorie, n’importe qui, y compris un citoyen qui n’est pas un chercheur académique, pourrait répliquer ces expériences. C’est là que la mise à disposition du code sous licence libre est intéressante : la communauté qui tourne autour de l’informatique est bien plus large que les chercheurs académiques. Libérer le code permet d’avoir des retours sur les travaux scientifiques, mais également de pouvoir transférer la recherche à disposition de tout le monde (avancées en terme de performances, et contre-mesures de sécurité par exemple). C’est une nécessité dans le sens où la recherche publique est financée en partie par les citoyens. Ceux-ci devraient donc pouvoir accéder aux résultats des études librement. La communauté académique se bat déjà pour que ce soit le cas au niveau des articles, qui sont souvent rendus payants par les grands éditeurs.

Pour le code, la problématique est différente. Avoir le code des chercheurs est un bon départ, mais c’est souvent le début des galères : le code ne compile pas toujours, quand il compile il est souvent peu documenté et ce n’est pas forcément évident d’en interpréter les résultats. Cette partie là, ainsi que la reproduction des expériences, est encore peu reconnue et valorisée dans le monde académique. Fournir du code (ré)utilisable requiert un long travail, qui passe souvent à la trappe dans le monde académique, car les préoccupations des chercheurs sont nombreuses : publier d’autres résultats, enseigner, servir la communauté au travers de relectures par exemple, chercher des financements...

Dans mon domaine en particulier, il est également difficile de reproduire des expériences car les attaques dépendent du matériel, il n’est donc pas évident de rendre les attaques génériques. Un autre problème lié est le matériel lui-même, assez souvent peu documenté. Comme toutes ces attaques nécessitent une très bonne compréhension du matériel, une partie de mon travail consiste en la rétro-ingénierie du matériel. En un sens, on ouvre le matériel également :)

> Si nous revenons un peu sur ta conférence, son sujet est pour le moins pointu. Pourrais-tu tout d’abord expliquer les grands principes des attaques par canaux auxiliaires pour les personnes qui ne les connaissent pas ? De même, l’idée d’impacter le navigateur par ce biais n’est là que pour illustrer le propos ou le navigateur est particulièrement sensible, en tant que logiciel, à ce type d’attaque ?

Le sujet est pointu, mais les grandes idées sont finalement connues de tous. L’idée générale des attaques par canaux auxiliaires est de trouver un moyen (un canal donc) par lequel une information secrète fuit, qui n’est pas le canal principal. On a tous vu un film dans lequel un personnage ouvre un coffre en utilisant un stéthoscope. Le canal principal c’est juste l’information logique "le coffre est-il ouvert ?". Il est difficile d’attaquer le coffre en ayant juste cette information : il faut essayer toutes les combinaisons. Le canal auxiliaire est ici le bruit que fait le coffre, et qui donne des informations à des stades intermédiaires (par exemple un "clic" quand un numéro est le bon). Si le coffre est vulnérable, un attaquant a moins de combinaisons à essayer.
On ne travaille pas sur des coffres forts, mais l’idée est la même : le matériel, sur lequel tourne le logiciel, offre tout un tas d’informations sur l’exécution des logiciels, de manière involontaire. On a par exemple la consommation de courant, ou les rayonnements électromagnétiques. Ces attaques nécessitent un accès physique au matériel. Je m’intéresse moi aux attaques qui vont cibler la micro-architecture de l’ordinateur, c’est à dire toute l’organisation interne des ordinateurs et des processeurs. Les caches des processeurs sont une petite mémoire qui se situe entre les coeurs du processeur (qui effectuent les calculs) et la DRAM (qui garde les données et le code en mémoire principale). Les coeurs sont de plus en plus rapides, mais la DRAM est trop lente, on a donc besoin d’une petite mémoire, très rapide et proches des coeurs pour ne pas créer de "bouchons". Les données comme le code se trouvent donc dans le cache. L’attaquant cherche à savoir les opérations que la victime vient de faire, pour en déduire ses secrets.
L’idée d’impacter le navigateur est que le matériel est partagé par toutes les applications qui tournent dessus. Le navigateur en fait partie, et c’est également le cas pour des machines virtuelles par exemple. Une particularité des attaques par canaux auxiliaires qui utilisent le cache, est qu’elles ne font que des opérations bénignes. Il n’est pas possible de juste "regarder dans le cache". L’attaquant ne fait que des accès mémoires à ses propres données, pour en déduire les opérations de la victime. Ce sont donc des opérations qui sont permises dans tous les environnements, y compris dans les sandboxes comme JavaScript. On oublie assez souvent que JavaScript est en pratique de l’exécution de code sur sa machine ! Le navigateur est sensible à ces attaques car une page n’a pas besoin de demander d’autorisation ou d’installer un quelconque logiciel pour exécuter son code. L’idée est que bien que les vulnérabilités soient présentes à bas niveau (le matériel), elles sont exploitables à haut niveau (un navigateur web). Ce type d’attaque est pris au sérieux par les développeurs de navigateurs web, qui cherchent des solutions pour les éviter. Le problème est cependant difficile à patcher, car les vulnérabilités viennent des optimisations matérielles - et qu’on ne veut pas sacrifier la performance.

> De manière plus globale, quelles sont tes attentes par rapport à ta présentation et plus généralement par rapport à ton passage aux RMLL ?

J’espère d’abord réussir à rendre nos travaux compréhensibles pour les participants !
J’ai participé (en tant que spectatrice et présentatrice) à plusieurs conférences "de hackers" comme le CCC, mais c’est mon premier passage aux RMLL, je suis contente de rencontrer cette communauté libriste :)

> Merci beaucoup pour ta disponibilité Clémentine et rendez vous mardi 4 Juillet à Saint Etienne pour ta conférence !

Entretien réalisé par messagerie électronique fin mai 2017.

[1] http://www.findresearch.org/