En matière de cybersécurité, l’open source est un bon point de départ, mais pas suffisant pour autant. La traçabilité des composants est aussi importante, comme nous le rappelle l’affaire Supermicro. Quels sont les risques et les solutions envisagées sur ces sujets ? Une demi-douzaine de chercheurs répondent à ces questions.

La semaine dernière, Emmanuel Macron annonçait une stratégie cyber avec un milliard d’euros à la clé. Afin de revenir sur les ambitions de ce plan, le CEA, le CNRS et Inria organisaient une conférence commune pour faire un point de la situation de la recherche en France. 

Durant cette présentation, sur laquelle nous aurons l’occasion de revenir en détail, nous avons interrogé les chercheurs sur un point en particulier de la cybersécurité : les projets open source. Nous avions évidemment en mémoire la faille Heartbleed d’OpenSSL, qui a fait trembler Internet il y a maintenant sept ans. 

• OpenSSL : la faille Heartbleed menace la sécurité du web, des sites ferment

Des méthodes formelles à un « cyber centaure »

Pour Ludovic Mé, adjoint au directeur scientifique en charge du domaine de recherche Cybersécurité à Inria, il y a deux aspects à cette problématique. Il commence par voir le côté positif et rappelle qu’il y a « un certain nombre de failles dans SSL qui ont été découvertes grâce aux travaux académiques », notamment ceux « liés au domaine des méthodes formelles ».

• Cybersécurité : on peut prouver que « la sécurité parfaite n'existe pas »
• Cybersécurité : le miroir aux alouettes de l’open source, la confiance dans les composants
• « Un jour ou l'autre on sera attaqué » : cryptographie et méthodes formelles au chevet de la cybersécurité
• En cybersécurité, « la maîtrise totale est sans doute totalement hors de portée »

Pour résumer il s’agit de « techniques informatiques d'une grande rigueur permettant, à l'aide de langages spécialisés et de règles logiques, de s'assurer (idéalement) de l'absence de tout défaut de programmes informatiques », rappelle l’Universalis.

Le chercheur explique que, dans certains cas, « les failles et les attaques correspondantes étaient tellement compliquées qu’on ne pouvait pas les trouver avec un crayon et un papier pour le dire simplement ». « C’est le monde académique qui a découvert les failles et c’est le monde académique qui a produit en association avec Microsoft, pour être très précis, une nouvelle version de SSL exempte de ces failles », affirme-t-il.

Cette technique d’« épauler l’expert – l’être humain – avec des capacités automatisées, y compris à base de machine learning », est prometteuse pour Florent Kirchner, responsable du programme Cybersécurité du CEA List. Pour détailler son propos, il reprend la notion de Centaure (une créature mi-homme, mi-cheval de la mythologie) notamment utilisée par le Grand Maitre des échecs Garry Kasparov, pour qui une association « entre l’homme et la machine, qui en fait joue mieux que l’homme tout seul ou la machine toute seule ».

Pour Florent Kirchner, cette collaboration serait particulièrement efficace dans le cas de l’analyse d’un système : « Un cyber centaure c’est quelque chose que demain on va continuer d‘explorer […] et montrer que cette complémentarité libère du temps aux experts, apporte une valeur ajoutée significative pour leur permettre de se concentrer sur les problèmes intéressants et importants », affirme-t-il.

Le responsable du programme Cybersécurité du CEA List voit ce cyber centaure comme l’« organisation ultime en matière de cybersécurité ». Pour Ludovic Mé, c’est la preuve que « les travaux académiques peuvent avoir un impact extrêmement réel ».

Le risque zéro n’existe pas

A contrario, une seconde lecture de cette douloureuse affaire Heartbleed peut être faite : « Est-ce que ça change aujourd’hui ? Si on disait les choses un peu rapidement on dirait : "non, ça n’a pas changé aujourd’hui" ». Pour le chercheur, le fond du problème est « qu’on ne peut jamais assurer qu’il n’y a pas une faille résiduelle dans [un] système ; qu’il soit ouvert ou fermé ne change rien ».

Cette remarque est valable pour tous les systèmes, mais le risque se multiplie lorsqu’un même logiciel est largement utilisé, ce qui était le cas d’OpenSSL. Ludovic Mé précise néanmoins que, comme de nombreux autres chercheurs du milieu académique, il pense que « si c’est ouvert c’est mieux, mais ce n’est pas une garantie complète non plus ».

Il s’explique :

« Le système est tellement compliqué, il y a tellement de dizaines de milliers de lignes de code que personne n’est capable d’assurer qu’effectivement tout a été revu. Et même si tout a été revu, toutes les failles n’ont pas été découvertes. Il est impossible d'éliminer le problème, c’est pour ça que la réponse un peu rapide serait de dire "non, ce n’est pas mieux aujourd’hui" ».

Point positif : il y a une « espèce de sensibilité globale à ce problème-là qui a augmenté, en particulier car il y a eu des cas comme ceux que vous mentionnez avec Heartbleed ». D’autres failles ont depuis fait trembler Internet et tomber certains protocoles de sécurité, renforçant la prise de conscience collective (souvent tardive). Mais il reste encore tellement de mauvaises pratiques, de « bugs », de défauts de conception… On est toujours surpris de les voir faire surface lorsqu’ils entrainent des fuites de données personnelles.

 « Open source » ne sont pas deux mots magiques en cybersécurité

Gildas Avoine, directeur du GDR CNRS Sécurité informatique et professeur de l’INSA Rennes à l’Institut de recherche en informatique et systèmes aléatoires, apporte son grain de sel sur la question de l’open source : « Ce qui est clair aujourd’hui [et] prôné par la communauté académique, c’est que les algorithmes et le code soient ouverts. On ne doit plus faire de sécurité par obscurité ».

Pour appuyer ses dires, le directeur de recherche cite le principe du linguiste Auguste Kerckhoffs Van Nieuwenhof, consigné dans son traité de La cryptographie militaire de 1883 : « La sécurité d’un système de cryptement ne doit pas dépendre de la préservation du secret de l’algorithme. La sécurité ne repose que sur le secret de la clé », comme l’indique l’ANSSI dans guide des bonnes pratiques de la cryptologie.

Appliqué au monde moderne, ce principe « pourrait se traduire par l’open source », lâche Gildas Avoine. Son corolaire est tout aussi important : « la sécurité ne doit pas reposer sur le fait que le code n’est pas open source ».

« Bien souvent », personne n’a audité le code

Mais attention, si « open source » veut dire que tout le monde peut (en théorie) accéder au code source, cela ne signifie pas pour autant que des chercheurs passent des heures, semaines, mois ou années à le vérifier sous toutes les coutures… c’est même très loin d’être le cas : « Au final, il y a très peu de gens qui ont la compétence pour l’auditer, et bien souvent il n’y a personne qui l’a fait ». C’est malheureusement une triste réalité. 

Gildas Avoine en ajoute une couche : « Le code est dynamique, il évolue […] il y a différentes versions. Même s’il a été audité à un instant T, on s’aperçoit qu’il peut y avoir des failles qui arrivent un peu plus tard. C’était le cas de Heartbleed, une faille introduite avec le développement d’une nouvelle version ». Cette brèche était en plus passée sous les radars pendant plusieurs années. 

Pire encore selon Ludovic Mé : « quand une nouvelle version corrige, une faille est produite, il se passe parfois des mois, des années – des années – avant qu’elles soient déployées concrètement sur 99 % des systèmes. La faille résiduelle, même corrigée, est présente souvent pour de nombreuses années ». Dans le cas de Heartbleed par exemple, près de 200 000 serveurs étaient toujours vulnérables trois ans après la mise en ligne des correctifs. C’est un problème beaucoup plus large, que l’on retrouve par exemple dans les objets connectés embarquant d'anciens noyaux Linux, les ordinateurs, etc.

Pour résumer, « il faut être vigilant avec le code open source », explique Ludovic Mé. Même si l’open source est largement soutenue par le monde académique et que certaines sociétés sautent le pas notamment pour essayer de montrer qu’elles n’ont rien à cacher, « on n’a aucune garantie de sécurité parce que le code est open source ».

Supermicro : la crédibilité des déclarations de Bloomberg

Durant la conférence, le sujet des micropuces chinoises espionnes sur des cartes mères Supermicro est revenu sur le devant de la scène. Jacques Fournier, chef du laboratoire de sécurisation des objets et systèmes physiques du CEA Leti, était le premier à répondre : « Je n’ai pas d’information, je ne peux pas confirmer quoi que ce soit sur les révélations de Bloomberg ».

• Micropuces chinoises sur des cartes mères : Bloomberg en remet une couche, Supermicro réfute

Il ajoutait néanmoins que c’est « effectivement une problématique qui est aujourd’hui existante […] On a des chaines d’approvisionnement de plus en plus complexes, qu’on n’arrive plus à tracer. Sur certains objets connectés et déploiements de systèmes critiques, ça peut poser problème ». Avec d’autres chercheurs et des partenaires privés, Fournier travaille sur des « processus qui permettent de réduire et mitiger les risques de supply chain ».

Florent Kirchner, responsable du programme Cybersécurité du CEA List, est plus sceptique : « jusqu’ici, il n’y a rien qui est venu prouver ces révélations là. On n’a pas trouvé ces puces chinoises. On aurait pu imaginer qu’en deux ans, on s’était laissé assez de temps pour regarder tout ça ».

Comme nous l’avions expliqué, des sociétés avec d’énormes moyens et de forts enjeux sur le sujet de la confidentialité (Amazon, Apple, OVH) se sont penchées sur ce sujet sans rien trouver jusqu’à présent. « Je prendrais ces révélations de Bloomberg avec une dose un peu sérieuse de sel en termes de crédibilité », ajoute Florent Kirchner. 

Des choses qu’on a « du mal à expliquer » dans les processeurs

Cela ne doit par contre pas cacher le fond du problème, comme nous l’avions déjà expliqué : « On a des composants qui viennent de partout dans le monde, et qui sont intégrés un peu partout dans le monde, qu’on reçoit ensuite et dans lesquels se pose fondamentalement la question de "est-ce que je peux avoir confiance ?" » ; une question valable aussi bien pour la partie logicielle que matérielle.

On touche ici à la question de la souveraineté numérique : « qu’est-ce qu’on veut maitriser, en quoi on a confiance, comment on fait pour établir la confiance ? », se demande Ludovic Mé.

Ce dernier ajoute : « je ne sais pas quel est le statut juridique de ça, mais reverser [au sens rétro-ingénierie, ndlr] les processeurs de nos amis ou moins amis américains ou d’ailleurs, pour voir ce qu’il y a dedans. Ceux qui le font savent et voient qu’il y a parfois des choses qu’ils ont du mal à expliquer dans ces processeurs. C’est avéré pour le coup ».